Thread (18 messages) 18 messages, 9 authors, 2011-05-18

Re: Identifying network namespaces (was: Network namespace manipulation with file descriptors)

From: Alexey Dobriyan <hidden>
Date: 2011-05-18 13:03:03
Also in: linux-arch, linux-fsdevel, lkml

On Wed, May 18, 2011 at 3:43 PM, David Lamparter [off-list ref] wrote:
-   processes cannot easily be cross referenced with each other

 in the case of user space stuff running astray - like management
 software crashing, routing daemons screwing up, etc. - it becomes
 fairly difficult to shut down a network namespace (or even reaquire
 physical devices that have been reassigned)
It shutdowns itself when last process using netns disappeares,
so if you kill your routing daemons you should be fine.
Physical netdevices are moved to init_net.
-   namespaces cannot adequately be identified to the user

 for debugging, some kernel messages become useless. most prominently,
 "unregister_netdevice: waiting for lo to become free. Usage count = 123"
 could certainly use some clarification, *which* lo is meant...
There is no "netns %p" or something, because right now the only unique
netns identifier is kernel pointer (which better not be exposed to userspace).
Printing such thing would be quite useless since it's not printed
at netns creation.
So, considering this set of premises (feedback welcome) I looked for
some suitable means of identification. I discarded going for any process
identifiers since Eric's patches allow for network namespaces without
any process holding a reference, using bind mounts instead.
If anything it should be netns->id, /proc/*/netns outputting id
where id is not derived from kernel pointer.
Solution?
=========
What a hack! :-)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help