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

[Moritz KLAMMLER (FERCHAU)]

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