Re: [PATCH 3/3] Refactor atfork handlers

[Florian Weimer <fweimer at redhat dot com>]

On 02/23/2018 01:10 PM, Adhemerval Zanella wrote:
> MY understanding is ld.so locks might be acquired in the callback calls from
> __run_fork_handlers:
>
>    fork:
>      __run_fork_handlers (atfork_run_prepare)
>        lll_lock (atfork_lock)
>        <callback>
>           rtld load lock

Yes, that could happen even with the existing code.

My concern was with certain downstream patches in some distributions 
which acquire the rtld lock around fork, to avoid potentially corrupting 
the dynamic linker state in the child process (because the fork can no 
longer race with rtld data structure updates).

> However I do not see who in a different thread dlopen would acquire the same
> lock since it has been already acquired by the callback.  The only way is if
> dlopen is being called by a signal handler, which I think it another obscure
> corner case.

I meant that one thread would acquire the rtld lock first, and another 
thread would attempt to acquire the atfork lock, and then they proceed 
to acquire the opposite lock, which will deadlock.

Thanks,
Florian