[Bug nptl/17214] Expose a function to reset the PID cache

["sstewartgallus00 at mylangara dot bc.ca" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17214

--- Comment #5 from Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc.ca> ---
> Why does clone(CLONE_NEWPID|CLONE_NEWUSER)+fork leave the process
> unable to use multiple threads afterwards?

CLONE_NEWPID gives a new PID namespace. Cloning off a new thread after
the PID namespace has been unshared would end up with two threads in
the same thread group being in two different PID namespaces. Not only
is that confusing and weird but it is also possibly a security
problem. As a result, unshare(CLONE_NEWPID) isn't allowed to be used
with other threads running and other threads can't be created after
unshare(CLONE_NEWPID).

> What race condition is there in pthread_join?

It's not really a problem in pthread_join or I wouldn't expect GLibc
to put in the difficult work to solve this case but it seems as if
pthread_join sometimes returns before a thread has been fully
destroyed (and only mostly destroyed). The basic problem is that
thread reports that it is destroyed BEFORE __exit_thread_inline is
called. Obviously, it is impossible (or at least would be really
hacky) for a thread to report that it is destroyed AFTER exiting. Of
course, there is always the possibility of asking for kernel
developers to create a system call to atomically report that a thread
is destroyed and destroy it at the same time. But I don't think this
use case is all that important. It might also be possible to use
waitpid with __WALL to solve this problem.

> I expect that you are not doing this with threads running. If you
> clone after having created a thread the userspace thread structure
> will still holds the old tid, and we use that for various purposes
> (locking, signaling, threaded forking) which are now wrong in the
> currently new PID namespace.

Yes.

> Exit from the first task (PID 1) and leave the child (PID 2) running?

Actually, I can't. Remember, if (PID 1) exits the whole system goes
down so PID 1 has to wait on PID 2 and report PID 2's exit status.

> > My code works without having a method to reset the PID cache but I
> > think with such a method it would be much simpler and more robust.

> I don't disagree and this problem has come up once before from the
> linux containers people who have to do odd things to work around the
> issue.

> I've emailed the lxc to ask them what they did.

Thank you very much.

-- 
You are receiving this mail because:
You are on the CC list for the bug.