Re: [PATCH v2 00/19] Fix various NPTL synchronization issues

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Adhemerval Zanella:

> This is an update of my previous set to fix some NPTL issues [1].
> The main changes are:
>
>   - Rebased against master and adjusted the __clone_internal usage.
>   - Adapted Florian's ESRCH fixes [2]
>   - Add fixes for various function that access the 'tid'.
>
> Patch 01 to 03 are general nptl fixes and they are independent of the
> other fixes.
>
> Patch 04 is the main change of this patchset, it uses a different
> field instead of the pthread 'tid' to synchrnonize the internal
> thread state (BZ#19951).
>
> It allows to both move the thread setxid internal state out of
> 'cancelhandling' (used on setuid() call in multi-thread information),
> and remove the EXITING_BIT and TERMINATED_BIT (since 'joinstate' now
> track such it).  This is done on patch 05 and 06.
>
> Patches 08 and 09 fixes two long standing issues regarding
> pthread_kill() and thread exit (BZ#12889 and BZ#19193).  Now that]
> 'tid' is setting explicitly by pthread_create(), a simple lock can be
> used instead of more complex futex operation.
>
> Patches 10 to 18 extend the same 'tid' access fix to other pthread
> functions that uses the member.

I don't think this series of patches is suitable for backport to glibc
2.34 once completed.  The libpthreaddb changes look particularly
cumbersome because you'll need two versions of the library depending
which coredumps you are investigating.  However, I expect that we need
to fix the pthread_cancel race in glibc 2.34.

I can send my previous attempt with a straightforward lock (and perhaps
with the callback-based function removed).

However, I'd like to know what people think about relying on signal
unblocking delivering the signal that was sent to the thread itself.
Do we need to special-case the pthread_self case or not?

Thanks,
Florian