Greg Kurz <gkurz@xxxxxxxxxx> writes: > Since pid namespaces were introduced, there's a recurring demand: how one > can correlate a pid from a child pid ns with a pid from a parent pid ns ? > The need arises in the LXC community when one wants to send a signal from > the host (aka. init_pid_ns context) to a container process for which one > only knows the pid inside the container. You are missing taking the sighand lock which is needed to make task_active_pid_ns safe when called on something other than current. I really don't like the name VPid, perhaps Process Pid. There is nothing more or less virtual about any pid, so calling any of the virtual is not clear, and misleading. I'm not exactly certain that /proc/self/status is the right place for this but this does seem reasonable. For what it's worth if you are communicating through anything except a pid file unix domain sockets will give you a race free to get the pid of the process on the other end. > In the future, this should be achievable thanks to Eric Biederman's setns() > syscall but there's still some work to be done to support pid namespaces: > > https://lkml.org/lkml/2011/5/21/162 > > As stated by Serge Hallyn in: > > http://sourceforge.net/mailarchive/message.php?msg_id=27424447 > > "There is nothing that gives you a 100% guaranteed correct race-free > correspondence right now. You can look under /proc/<pid>/root/proc/ to > see the pids valid in the container, and you can relate output of > lxc-ps --forest to ps --forest output. But nothing under /proc that I > know of tells you "this task is the same as that task". You can't > even look at /proc/<pid> inode numbers since they are different > filesystems for each proc mount." As it happens a unix domain socket can be used to give you a guaranteed race-free correspondence right now. So that is what I would recommend if your source of the pid is something other than a pid file sitting in the filesystem. > This patch adds a single line to /proc/self/status. Provided one has kept > track of its container tasks (with a cgroup like liblxc does for example), > he may correlate global pids and container pids. This is still racy but > definitely easier than what we have today. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
