This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/3] Refactor atfork handlers
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?