This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [BZ #15392] Remove fork child pid assertion
- From: Torvald Riegel <triegel at redhat dot com>
- To: Ricky Zhou <rickyz at google dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 18 Nov 2014 15:32:14 +0100
- Subject: Re: [PATCH] [BZ #15392] Remove fork child pid assertion
- Authentication-results: sourceware.org; auth=none
- References: <1416014955-5408-1-git-send-email-rickyz at chromium dot org> <1416220691 dot 4535 dot 385 dot camel at triegel dot csb> <CAJmxDmQDP8N7cLE9MZwB0jFSES=eodx8cAjGwNPZNQT_8mbrFA at mail dot gmail dot com>
On Mon, 2014-11-17 at 14:20 -0800, Ricky Zhou wrote:
> On Mon, Nov 17, 2014 at 2:38 AM, Torvald Riegel <triegel@redhat.com> wrote:
> > On Fri, 2014-11-14 at 17:29 -0800, Ricky Zhou wrote:
> >> This assertion is no longer always true, since a forked child may be in
> >> a different PID namespace than its parent, and the two namespace may
> >> have PID collisions.
> >
> > If that's true, process-shared synchronization facilities based on the
> > thread ID (e.g., mutexes) might not work anymore.
> >
> > Do we at least need a note in the documentation that this is the case?
> > Or do we still need to implement it?
> >
> > Is there any glibc-internal synchronization that this could break?
> >
> > I believe we deal with these issues before dropping the assert.
> Within a PID namespace, all thread IDs should remain unique, and a
> process cannot have threads in different PID namespaces
> (http://lxr.free-electrons.com/source/kernel/fork.c#L1217), so I'm
> having trouble coming up with a situation where removing this assert
> would allow badness to happen down the line.
Okay, so private (intra-process) mutexes and such are safe. However,
what about process-shared mutexes?