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

[Adhemerval Zanella Netto]

On 20/04/26 11:25, Moritz KLAMMLER (FERCHAU) wrote:
>> 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.
> 
> Should I update the patch accordingly to have only error-checking PI
> mutex propagate the EDEADLK and deliberately deadlock in all other
> cases?  Running into the assertion seems to be the least desirable
> option to me.

I think this should a reasonable approach, I am not sure if Florian still
think this might not be acceptable.