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