Re: [PATCH] [BZ #15392] Remove fork child pid assertion

[Ricky Zhou <rickyz at google dot com>]

On Tue, Nov 18, 2014 at 7:57 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 11/18/2014 08:51 PM, Ricky Zhou wrote:
>> Ah, I see, I didn't know about process-shared mutexes - those
>> definitely won't work across PID namespaces (and this should
>> definitely be documented). Do you know of any other places in glibc
>> where we may be assuming that PIDs are unique between processes that
>> may be in different PID namespaces? I think it'd be useful to have a
>> list of these.
>
> PID uniqueness is a requirement for POSIX, everything can rely on it.
>
> Documenting the functions which depend on it will lock down the
> implementation's flexibility.
My goal with documenting functions that depend on PID uniqueness isn't
to lock down the implementation, but rather to lock down people that
decide to use PID namespaces. For example, someone using PID
namespaces should be aware that they cannot use process-shared mutexes
across the PID namespace.

> You are asking to support a POSIX API with a set of semantics that
> violate the contract of that API. I would like to avoid this.
Is the concrete fear that future changes to glibc internals may want
to rely on the uniqueness of PIDs across fork? I'm not trying to argue
one way or the other here - I just want to better understand the
reasoning for disallowing fork after setns/unshare.

I haven't fully read through the fork code, but it seems to reset some
other glibc internal state, and someone using setns/unshare might want
that behavior as well.

> Using clone is fine, since clone has none of the POSIX requirements
> that fork, or vfork have.
Does this mean that developers should implicitly know that features
like process-shared mutexes won't work across clones into a new PID
namespace because clone is not a POSIX API?

> Then let us go in this direction, make clone better, and recommend
> it as the only way to create a new process after setns/unshare.
>
>> 1) Provide an interface to reset the PID cache (this would allow us to
>> use the syscall directly).
>
> Why do you need this if you have a version of clone that resets it for you?
>From my perspective, this could potentially be useful in the (probably
not too likely) situation where Linux adds some new method for
creating a process that we want to use before glibc has a wrapper for
it. I'm fine with the other approach of adding a new clone wrapper as
well though.

> I think a new fork-like clone wrapper should be acceptable, we'll have
> to iterate on the design a bit, but I don't object to the idea.
Cool, I'll send out an RFC in a bit to start talking about what this
interface should look like.

Thanks,
Ricky