FAILING nptl/tst-robust8pi

[Stefan Liebler]

On 18.01.24 15:58, Stefan Liebler wrote:
> Hi,
> 
> I've observed (on s390x) that nptl/tst-robust8pi sometimes fails (e.g.
> if run it multiple times in a loop). I only see it with linux 6.7 (some
> release-candidate, not the release) and linux 6.8 (thus I assume it will
> also fail with the real 6.7 release).
> 
> In each case it fails with something like this:
> mutex_timedlock of 66 in thread 7 failed with 22
> => pthread_mutex_timedlock returns 22=EINVAL
> 
> If I reboot with linux 6.6.9 and run the same binary again, I don't see
> fails.
> 
> Does anybody else see such fails?
> 
> I've reduced the test (see attachement) and now have only one process
> with three threads. I only use one mutex with attributes like the
> original testcase: PTHREAD_MUTEX_ROBUST_NP, PTHREAD_PROCESS_SHARED,
> PTHREAD_PRIO_INHERIT.
> Every thread is doing a loop with pthread_mutex_timedlock(abstime={0,0})
> and if locked, pthread_mutex_unlock.
> 
> There is a hint in <glibc>/nptl/futex-internal.c:__futex_lock_pi64():
> case -EINVAL:
>   /* This indicates either state corruption or that the kernel
>   found a waiter on futex address which is waiting via
>   FUTEX_WAIT or FUTEX_WAIT_BITSET.  This is reported on
>   some futex_lock_pi usage (pthread_mutex_timedlock for
>   instance).  */
> 
> 
> I've added some uprobes before and after the futex-syscall in
> __futex_lock_pi64(in pthread_mutex_timedlock) and futex_unlock_pi(in
> pthread_mutex_unlock). For me __ASSUME_FUTEX_LOCK_PI2 is not available,
> but __ASSUME_TIME64_SYSCALLS is defined.
> 
> For me it looks like this (simplified ubprobes-trace):
> <thread> <timestamp>: <probe>
> t1 4309589.419744: before syscall in __futex_lock_pi64
> 
> t3 4309589.419745: before syscall in futex_unlock_pi
> t2 4309589.419745: before syscall in __futex_lock_pi64
> 
> t3 4309589.419747: after syscall in futex_unlock_pi
> t2 4309589.419747: after syscall in __futex_lock_pi64 ret=-22=EINVAL
> 
> t1 4309589.419748: after syscall in __futex_lock_pi64 ret=-110=ETIMEDOUT
> 
> 
> Is this a kernel bug due to a recent change?
> Or is this valid kernel behavior?
> And should glibc handle it?
> 
> Bye,
> Stefan

In the meanwhile I also retested with glibc 2.38 release tag to be sure
there was no glibc change in between. => same test error.

I also created a kvm-guest on my x86_64 machine with fedora 39 and used
this kernel from copr-repository:
Linux fedora 6.7.0-0.rc8.20240107gt52b1853b.366.vanilla.fc39.x86_64 #1
SMP PREEMPT_DYNAMIC Sun Jan  7 06:17:30 UTC 2024 x86_64 GNU/Linux
=> Now I also see the EINVAL on x86_64

@Florian / @Carlos: Have you already saw this on fedora side?