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

[Adhemerval Zanella]

On 26/08/2021 11:47, Florian Weimer wrote:
> * 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 thin for fix the pthread_cancel race on glibc 2.34 only the fix
for BZ#19951 along with your patch should be suffice.  I don't think
this is cumbersome, but I didn't considered the coredump (which I
also don't think it should be blocker though).

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