Re: [PATCH 3/3] Refactor atfork handlers

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 20/02/2018 10:58, Florian Weimer wrote:
> On 02/20/2018 02:48 PM, Adhemerval Zanella wrote:
> 
>> The atfork_run_prepare will instruct __run_fork_handlers to take the internal
>> atfork_lock handler:
>>
>>    void
>>    __run_fork_handlers (enum __run_fork_handler_type who)
>>    {
>>      struct fork_handler *runp;
>>
>>      if (who == atfork_run_prepare)
>>        {
>>          lll_lock (atfork_lock, LLL_PRIVATE);
>>
>> And it will prevent to add new registration until either the parent or the child
>> call __run_fork_handlers with either 'atfork_run_child' or 'atfork_run_parent'
>> to release the lock.
> 
> Oh, sorry, I missed that.  So the patch does not have this problem. This does not settle the deadlock issue, though.

Aside of the two scenarios (callbacks issuing fork/pthread_atfork), the only
other scenario I see which might trigger a deadlock in this case is a signal
handler issuing fork/pthread_atfork.  

Former is BZ#4737 and my understanding is this should be a EWONTFIX due 
indication future POSIX specification to interpret fork as async-signal-unsafe 
(comment #19 and I am not sure if fork could be made async-signal-safe with 
ticket locks as Rich stated in comment #21).  

Regarding later I think pthread_atfork is inherent async-signal-unsafe due
it might return ENOMEM indicating it might allocate memory and our malloc
is also async-signal-unsafe.

Am I missing a scenario you might be considering?