From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3361 invoked by alias); 1 Aug 2014 21:59:22 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 3332 invoked by uid 48); 1 Aug 2014 21:59:18 -0000 From: "sstewartgallus00 at mylangara dot bc.ca" To: glibc-bugs@sourceware.org Subject: [Bug nptl/17214] Expose a function to reset the PID cache Date: Fri, 01 Aug 2014 21:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sstewartgallus00 at mylangara dot bc.ca X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-08/txt/msg00004.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17214 --- Comment #5 from Steven Stewart-Gallus --- > 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.