Re: [PATCH RFC] pidns: introduce syscall getvpid

Konstantin Khlebnikov [off-list ref] writes:

On 21.09.2015 17:22, Serge E. Hallyn wrote:

quoted

So please implement it, as Eric suggested, using the ns inode fds
instead of racy pid_t hints for namespaces.

I don't want to loose simple way to use it.
Sometimes caller cannot prevent races (task its child or
locked with with ptrace) or it don't care about them.

What about this design:

pid_t getvpid(pid_t pid, pid_t source, pid_t target)

pid > 0 - get vpid of task
pid = 0 - current pid (= just for symmetry =)
pid < 0 - get vpid of parent task (ppid of -pid)
          [ that's really useful for poking isolated pidns ]
source/target > 0 - pid of source/target task
source/target = 0 - use current as source/target
source/target < 0 - use pidns fd (1-arg) as source/target

or the same but without =0 sugar:

pid > 0 - get vpid of task
pid < 0 - get vpid of parent task (ppid of -arg)
source/target > 0  - pid of source/target task
source/target <= 0 - use pidns fd (-arg) as source/target

libc caches current pid, extra getpid shouldn't be a problem.

Yuck.  An invalid fd like for saying use the current pid namespace is
fine.

Using pids to identify namespaces yuck just yuck.  That just seems to
add complexity for no gain except to make programs buggier.

We have a couple of old interfaces that use pids because pids were the
the best we had, but at this point I don't see anything at all that
even suggests that pids are a good choice for identifying namespaces.

If performance is important than caching file descriptors should be
trivial.  If performance is not important it should not be hard to
open "/proc/<pid>/ns/pid".

I do not see the gain of using pids in this interface except to confuse
people, and make the interface brittle.


Eric