Messages in this thread | | | Date | Mon, 03 Mar 2008 11:52:49 +0300 | From | Pavel Emelyanov <> | Subject | Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces |
| |
Eric W. Biederman wrote: > Pavel Emelyanov <xemul@openvz.org> 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. > >>> 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.
>> 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 >
| |