Messages in this thread |  | | | Date | Wed, 18 May 2011 17:13:05 +0300 | | Subject | Re: Identifying network namespaces (was: Network namespace manipulation with file descriptors) | | From | Alexey Dobriyan <> |
| |
On Wed, May 18, 2011 at 4:33 PM, David Lamparter <equinox@diac24.net> wrote: > On Wed, May 18, 2011 at 04:03:03PM +0300, Alexey Dobriyan wrote: >> On Wed, May 18, 2011 at 3:43 PM, David Lamparter <equinox@diac24.net> 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. > > Now assume I'm running pptpd, which forks a new pppd for each > connection. Even if I kill pptpd, the pppd keeps running... now how do I > find the pppds that belong to that one namespace that I'm trying to > get rid of?
That's a valid question.
>> > 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.
Actually it should be symlink /proc/net/netns -> 0 # for init_net /proc/net/netns -> u32 (> 0) # for the rest to extract information by 1 syscall, not 3 where netns id is totally random, so userspace won't make assumptions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |