Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella:

> On 29/08/2019 05:38, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> 	* include/atomic.h (atomic_fetch_or_seq_cst, atomic_fetch_or_seq_cst):
>>> 	New macros.
>> 
>> Why isn't a regular release store/acquire load synchronization
>> sufficient here?
>
> It should works, my understanding is a weaker store barrier might incur in
> a slight more false positive in a highly concurrent sigaction call scenario.
> But I assume that this is not a common scenario, so I used the strongest
> barrier just to avoid the extra false positives.

I don't see how false positives are possible.  It would require bits
getting set which have never been added to the mask, which would be a
bug even for relaxed MO (as a QoI issue, the memory model is buggy and
allows this).

My main worry would be reading an outdated value in posix_spawn, but my
understanding is that the release store/acquire load synchronization
avoids that.

>> I wonder if we can get kernel support for this in the new clone system
>> call with more flags.  Then we don't have to complicate the sigaction
>> implementation.
>
> Maybe a CLONE_RESET_SIGNALS where the cloned process sets its signal
> disposition to default SIG_IGN/SIG_DFL values may help us here.  However
> afaik clone now is out of space on 'flags' for newer ones (it already
> defines 24 flags plus it reserve 8 bits for signal to be sent at process
> exit) and it would take time to use this feature on glibc.

Christian Brauner has been working on fixing this.

Thanks,
Florian