Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces

Pavel Emelyanov [off-list ref] writes:

I could use the struct net pointer values (obtained with sprintf(id, "%p", net))
instead, but exporting internal kernel addresses seemed even uglier.

Agreed.

quoted

Can you try this approach by capturing a struct pid instead of an id
in a new global namespace? 

This is a bad approach. When task, that created the namespace dies, his
pid is removed from the pidmap and can be reused, so we can get another
net with the same id.

It takes a little updating of how we use pids.  The easiest method
is to add an extra counter.  So we know when someone besides the hash
chains is using the pid as an id.  However it might make sense to actually
have a net namespace pointer in the pid.

This net's id is not supposed to be used to address any net in the kernel.
And I see no problems with migration - you can change the net's id safely
during checkpoint/restart - tasks will always see this one via the /proc/net
symlink, which is dynamic.

So you are really talking about a hidden id.  There are just enough
ways for something like that to slip out I'm not especially
comfortable with the idea.

I really think we need something clean that we can live with, and be
proud of.  However we implement the enhancement to /proc/net this has
to be maintained for decades.

Eric

Eric W. Biederman wrote:

Pavel Emelyanov [off-list ref] writes:

quoted

I could use the struct net pointer values (obtained with sprintf(id, "%p", net))
instead, but exporting internal kernel addresses seemed even uglier.

Agreed.

quoted

quoted

Can you try this approach by capturing a struct pid instead of an id
in a new global namespace? 

This is a bad approach. When task, that created the namespace dies, his
pid is removed from the pidmap and can be reused, so we can get another
net with the same id.

It takes a little updating of how we use pids.  The easiest method
is to add an extra counter.  So we know when someone besides the hash
chains is using the pid as an id.  However it might make sense to actually
have a net namespace pointer in the pid.

No, please, no. I'm strongly opposed to making pids provide identification
for anything we need in the kernel.

quoted

This net's id is not supposed to be used to address any net in the kernel.
And I see no problems with migration - you can change the net's id safely
during checkpoint/restart - tasks will always see this one via the /proc/net
symlink, which is dynamic.

So you are really talking about a hidden id.  There are just enough
ways for something like that to slip out I'm not especially
comfortable with the idea.

I really think we need something clean that we can live with, and be
proud of.  However we implement the enhancement to /proc/net this has
to be maintained for decades.

Eric