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

[Florian Weimer <fweimer at redhat dot com>]

* 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.

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

> 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.

Thanks,
Florian