public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sstewartgallus00 at mylangara dot bc.ca" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-17214-131-If81cMDyh4@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-17214-131@http.sourceware.org/bugzilla/> 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.
next prev parent reply other threads:[~2014-08-01 21:59 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-29 21:23 [Bug nptl/17214] New: " sstewartgallus00 at mylangara dot bc.ca 2014-07-30 4:07 ` [Bug nptl/17214] " carlos at redhat dot com 2014-07-30 17:39 ` sstewartgallus00 at mylangara dot bc.ca 2014-07-30 17:41 ` sstewartgallus00 at mylangara dot bc.ca 2014-07-31 23:25 ` carlos at redhat dot com 2014-08-01 21:59 ` sstewartgallus00 at mylangara dot bc.ca [this message] 2014-08-26 4:38 ` bugdal at aerifal dot cx 2014-08-26 18:11 ` sstewartgallus00 at mylangara dot bc.ca 2014-08-26 18:31 ` sstewartgallus00 at mylangara dot bc.ca 2014-10-30 22:01 ` rickyz at chromium dot org 2014-12-18 0:15 ` jld at mozilla dot com 2014-12-18 23:58 ` [Bug nptl/17214] Expose a clone variant that shares stacks instead of jumping to a new one sstewartgallus00 at mylangara dot bc.ca 2014-12-19 0:13 ` sstewartgallus00 at mylangara dot bc.ca 2014-12-19 1:17 ` bugdal at aerifal dot cx 2014-12-19 20:29 ` sstewartgallus00 at mylangara dot bc.ca 2014-12-19 21:01 ` bugdal at aerifal dot cx 2015-01-26 22:33 ` sstewartgallus00 at mylangara dot bc.ca
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=bug-17214-131-If81cMDyh4@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).