This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/3] Refactor atfork handlers

On 02/23/2018 01:10 PM, Adhemerval Zanella wrote:
MY understanding is locks might be acquired in the callback calls from

     __run_fork_handlers (atfork_run_prepare)
       lll_lock (atfork_lock)
          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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]