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

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 3879 bytes --]

On Mon, 19 Oct 2020 14:48:12 +0200
Stefan Liebler <stli@linux.ibm.com> wrote:

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

I've just posted the fix. I would be very grateful if you can test it
on s390. Thanks in advance.

> 
> Bye,
> Stefan




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]