Re: [PATCH] nptl: Avoid fork handler lock for async-signal-safe fork [BZ #24161]

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 04/02/2019 18:33, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> Now it has bitten us again, how should we proceed to handle async-safeness
>> for fork? Should we add signal handler wrapper so we can detect if fork
>> is called in a signal handler and handle the locks properly? Or should
>> we follow Rich suggestion in comment #21 at BZ#4737 and use a recursive
>> and reentrant lock?
> 
> For what?  This particular lock, or all potentially relevant locks?  The
> list of locks we'd need to fix is quite long.

My questioning was to make fork async-signal-safe for the generic way, not only
for single-thread as we currently aim to. Another question is whether we really
care to make fork async-signal-safe in all possible context, more specially
in multithread environments.

> 
> I think it's more promising to eliminate locks through STM techniques
> and also provide async-signal-safety this way.

There is an option I haven't considered yet. Not sure if it would be easier
to fix the reentracy issue with fork.

> 
>> I would prefer if handle it on fork instead, since the logic and requirement
>> of locking depends on how we define the fork semantics regarding atfork
>> handlers (and it already handler other locks in same manner).
> 
> Do you suggest to expose the lock as a global variable, and lock and
> unlock it in the fork implementation, as appropriate?  I'm not sure if
> that's an improvement.
> 

Thinking again, you are right. I will review the original patch.