Re: [PATCH v2] y2038: nptl: Convert pthread_mutex_{clock|timed}lock to support 64 bit

[Stefan Liebler via Libc-alpha <libc-alpha@sourceware.org>]

On 10/19/20 1:59 PM, Lukasz Majewski wrote:
> Hi Stefan,
> 
>> Hi Lukasz,
>>
>> With this commit, the testcase nptl/tst-robust10 times out on s390
>> (31bit, big-endian).
>>
>> For me it seems that one futex call was not adjusted while converting
>> abstime of __pthread_mutex_clocklock_common function from struct
>> timespec to struct __timespec64:
>> ┌──../nptl/pthread_mutex_timedlock.c
>> │   270                   /* Block using the futex.  */
>> │  >271                   int err = lll_futex_clock_wait_bitset
>> (&mutex->__data.__lock,
> 
> Yes. You are right. The lll_futex_clock_wait_bitset shall be converted
> as well... I must have overlooked it, sorry.
> 
>> │   272                       oldval, clockid, abstime,
>> │   273                       PTHREAD_ROBUST_MUTEX_PSHARED (mutex));
>> (gdb) where
>> #0  0x7dfb9948 in __pthread_mutex_clocklock_common
>> (mutex=mutex@entry=0x406144 <mutex>, clockid=clockid@entry=0,
>> abstime=abstime@entry=0x7ddf9290)
>>     at ../nptl/pthread_mutex_timedlock.c:271
>> #1  0x7dfb9c12 in __GI___pthread_mutex_timedlock64
>> (abstime=0x7ddf9290, mutex=0x406144 <mutex>) at
>> ../nptl/pthread_mutex_timedlock.c:632 #2  __pthread_mutex_timedlock
>> (mutex=mutex@entry=0x406144 <mutex>,
>> abstime=abstime@entry=0x7ddf930c) at
>> ../nptl/pthread_mutex_timedlock.c:644 #3  0x004020bc in thr
>> (arg=<optimized out>) at ../sysdeps/pthread/tst-robust10.c:33 #4
>> 0x7dfb6a06 in start_thread (arg=0x7ddf9b00) at pthread_create.c:463
>> #5  0x7df08434 in thread_start () at
>> ../sysdeps/unix/sysv/linux/s390/s390-32/clone.S:64
>>
>>
>> Thus the futex syscall interprets the struct __timespec64 as struct
>> timespec and the result is an infinite loop:
>> (gdb) p	abstime
>> $6 = (const struct __timespec64 *) 0x7ddf9290
>>
>> (gdb) p/x *abstime
>> $9 = {tv_sec = 0x5f8d597f, tv_nsec = 0xd79f074}
>>
>> (gdb) p/x *((struct timespec *) abstime)
>> $10 = {tv_sec = 0x0, tv_nsec = 0x5f8d597f}
>>
>> (gdb) x/4xw abstime
>> 0x7ddf9290:     0x00000000	0x5f8d597f	0x00000000
>> 0x0d79f074
>>
>>
>>
>> strace output:
>> 10:59:58.611688 futex(0x406144,
>> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2148981693, {tv_sec=0,
>> tv_nsec=1603098008}, FUTEX_BITSET_MATCH_ANY) = -1 EINVAL (Invalid
>> argument) <0.000006> 10:59:58.611707 futex(0x406144,
>> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2148981693, {tv_sec=0,
>> tv_nsec=1603098008}, FUTEX_BITSET_MATCH_ANY) = -1 EINVAL (Invalid
>> argument) <0.000006> 10:59:58.611724 futex(0x406144,
>> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2148981693, {tv_sec=0,
>> tv_nsec=1603098008}, FUTEX_BITSET_MATCH_ANY) = -1 EINVAL (Invalid
>> argument) <0.000006>
>>
>>
>> This is also observable on x86 (32bit). But there only tv_nsec is 0
>> and thus it does not result in an infinite loop:
>> 11:22:30.348352 futex(0x804f0f4,
>> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2147913074,
>> {tv_sec=1603099351, tv_nsec=0}, FUTEX_BITSET_MATCH_ANY) = -1
>> ETIMEDOUT (Connection timed out) <0.652043>
>>
>> Can you please have a look?
>>
> 
> I'm going to prepare and sent fixes ASAP. Big thanks for spotting it.
Thanks. Let me know, then I can run a test on s390 if you want.

Bye,
Stefan