This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls
On 30/08/2019 07:07, Florian Weimer wrote:
> * 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.
The false positives happens for the case where the signal disposition was
set, the bit in the bitmask set, and the signal disposition reset to default
value. The bit will be stick and posix_spawn will always issue the sigaction
(even though strictly it is not required).
The problem is in fact false negatives, where posix_spawn will get a mask
*without* the bit set, but with a set signal disposition. In fact I think
due the syscall, even relaxed operations would work (since the syscall acts
a strong memory barrier).
>
>>> 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.
Which strategy he is proposing? Even with proper kernel support, it would
take time to enable glibc to use it.