From: ebiederm@xmission.com (Eric W. Biederman)
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, equinox@diac24.net
Subject: Re: [PATCH] netns: add /proc/*/net/id symlink
Date: Sat, 21 May 2011 08:39:37 -0700 [thread overview]
Message-ID: <m11uzsxdty.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20110521093936.GA3015@p183> (Alexey Dobriyan's message of "Sat, 21 May 2011 12:39:36 +0300")
Alexey Dobriyan <adobriyan@gmail.com> writes:
> David Lamparter pointed some real scenarios where knowing
> if two processes live in same netns is important,
> like "how do I kill _all_ processes in netns to shutdown it".
Currently today the way I do this is md5sum /proc/<pid>/mounts.
That works because it is usually necessary to have a separate mount
namespace with a separate set of mounts to accommodate sysfs.
> Currently only kernel knows if two netns are the same.
> Userspace maybe can look at different proc files to find a match
> indirectly sysconf-style but result will be ugly no matter what.
Somewhat.
Right now today without patches if we limit ourselves to the network
namespace there is a pretty valid way to do this.
stat /proc/<pid>/net/dev and compare the inode numbers.
Or any other file in /proc/*/net/. The inode numbers are the
same if you are in the same network namespace.
> Add /proc/*/net/id symlink which "points" to an integer.
>
> $ readlink /proc/net/id
> 0
>
> $ readlink /proc/2941/net/id
> 1
>
> "id" is not a file because 1 syscall is faster than 3 syscalls.
>
> The only rules and expectations for userspace are:
> [as if they will comply, ha-ha]
>
> * init_net always has id 0
> * two netns do not have same id
> * id is unsigned integer
I don't like this patch because we already have a proc interface
that already solves this in production kernels today.
- stat is a single syscall
- two netns do not have the same id
- id is an ino_t.
Now it probably needs to be better documented that /proc/*/net/*
have the same inode number if the network namespace is the
same, as everyone including myself overlooked this very handy
existing property.
Writing this it occurs to me there is a misfeature in my pending
namespace file descriptor code. Right now /proc/<pid>/ns/net
has a floating inode number and it would be good if I could make
that a inode number be the same for every file that refers to
the same network namespace. Ugh.
Eric
next prev parent reply other threads:[~2011-05-21 15:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-21 9:39 [PATCH] netns: add /proc/*/net/id symlink Alexey Dobriyan
2011-05-21 15:39 ` Eric W. Biederman [this message]
2011-05-21 22:30 ` Alexey Dobriyan
2011-05-22 0:15 ` Eric W. Biederman
2011-05-23 1:43 ` David Lamparter
2011-05-23 1:47 ` David Lamparter
2011-06-17 23:31 ` [PATCH 1/2] proc: Generalize proc inode allocation Eric W. Biederman
2011-06-17 23:31 ` Eric W. Biederman
2011-06-17 23:33 ` [PATCH 2/2] proc: Usable inode numbers for the namespace file descriptors Eric W. Biederman
2011-06-17 23:33 ` Eric W. Biederman
2011-06-19 23:22 ` David Miller
2011-06-20 16:06 ` Serge E. Hallyn
2011-06-20 19:50 ` Eric W. Biederman
2011-06-19 14:20 ` [PATCH 1/2] proc: Generalize proc inode allocation Serge E. Hallyn
2011-05-23 2:02 ` [PATCH] netns: add /proc/*/net/id symlink Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m11uzsxdty.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=davem@davemloft.net \
--cc=equinox@diac24.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.