On Fri, May 19, 2017 at 05:48:50PM +0200, Peter Zijlstra wrote:
> Markus reported that the glibc/nptl/tst-robustpi8 test was failing after
> commit:
>
> cfafcd117da0 ("futex: Rework futex_lock_pi() to use
> rt_mutex_*_proxy_lock()")
>
> Much tracing later I managed to catch the culprit:
>
> ld-linux-x86-64-2161 [019] .... 410.760971: SyS_futex: 00007ffbeb76b028:
> 80000875 op=FUTEX_LOCK_PI
> ld-linux-x86-64-2161 [019] ...1 410.760972: lock_pi_update_atomic:
> 00007ffbeb76b028: curval=80000875 uval=80000875 newval=80000875 ret=0
> ld-linux-x86-64-2165 [011] .... 410.760978: SyS_futex: 00007ffbeb76b028:
> 80000875 op=FUTEX_UNLOCK_PI
> ld-linux-x86-64-2165 [011] d..1 410.760979: do_futex: 00007ffbeb76b028:
> curval=80000875 uval=80000875 newval=80000871 ret=0
> ld-linux-x86-64-2165 [011] .... 410.760980: SyS_futex: 00007ffbeb76b028:
> 80000871 ret=0000
> ld-linux-x86-64-2161 [019] .... 410.760980: SyS_futex: 00007ffbeb76b028:
> 80000871 ret=ETIMEDOUT
The above trace continues like:
ld-linux-x86-64-2164 [006] .... 410.762336: SyS_futex: 00007ffbeb76b028:
80000871 op=FUTEX_LOCK_PI
ld-linux-x86-64-2164 [006] ...1 410.762337: lock_pi_update_atomic:
00007ffbeb76b028: curval=80000871 uval=80000871 newval=80000871 ret=0
ld-linux-x86-64-2164 [006] .... 410.762347: SyS_futex: 00007ffbeb76b028:
80000871 ret=ETIMEDOUT
ld-linux-x86-64-2161 [019] .... 410.762521: SyS_futex: 00007ffbeb76b028:
80000871 op=FUTEX_LOCK_PI
ld-linux-x86-64-2161 [019] .... 410.762522: SyS_futex: 00007ffbeb76b028:
80000871 ret=EDEADLK
And every subsequent attempt by 2161 will (obviously) return EDEADLK.
Now since the test explicitly tracks the lock state[] and
pthread_mutex_*lock() return values this _should_ have triggered one of
the printf()'s, but I never saw any of those.
