[PATCH] nptl: futex_lock_pi deadlock detection provides valuable information but it is turned into a rather cryptic assertion failure

[Adhemerval Zanella Netto]

On 15/04/26 11:02, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 15/04/26 04:24, Florian Weimer wrote:
>>> * Carlos O'Donell:
>>>
>>>> If we aren't triggering undefined behaviour then I think it's perfectly
>>>> acceptable to return a "may fail" error to the caller.
>>>
>>> Doing that triggers undefined behavior in this case if the caller
>>> ignores the EDEADLK right, no?
>>
>> The 'may fail' for multi-mutex deadlock is defined even for POSIX 2001 [1],
>> so I am not sure if we can consider this UB.
>>
>> [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html
> 
> It's likely to end up in UB because the lock is not taken, the caller
> doesn't realize this, and enters the code for the critical section
> without any protection against data races.

But currently any program that issues this scenario will abort anyway,
and it also depends whether glibc is built with assert enabled.

It also follow the error-checking semantic that it *should* return
an error, so I think it is unlikely to cause a regression because
I would expect error checking is a standard when this mutex type is
used.

The recursive check *might* trigger some issues, but even then for 
non-pi mutexes this is a deadlock anyway.  Maybe just change for
error-checking and let robust fall the path of __futex_abstimed_wait64.