From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 182511F4B4 for ; Mon, 19 Oct 2020 15:00:18 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 21F8B388A42C; Mon, 19 Oct 2020 15:00:17 +0000 (GMT) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by sourceware.org (Postfix) with ESMTPS id DE7003857C4F for ; Mon, 19 Oct 2020 15:00:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DE7003857C4F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=lukma@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4CFKgJ5tZRz1rxxD; Mon, 19 Oct 2020 17:00:12 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4CFKgJ5dXPz1r0m2; Mon, 19 Oct 2020 17:00:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id ivBw2tH-_JTq; Mon, 19 Oct 2020 17:00:11 +0200 (CEST) X-Auth-Info: JwQ4/6AgS52wR2mgPVins0VdanXxVGm5SvAEP1jKpDU= Received: from jawa (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Mon, 19 Oct 2020 17:00:11 +0200 (CEST) Date: Mon, 19 Oct 2020 16:59:58 +0200 From: Lukasz Majewski To: Stefan Liebler Subject: Re: [PATCH v2] y2038: nptl: Convert pthread_mutex_{clock|timed}lock to support 64 bit Message-ID: <20201019165958.5f2e65c7@jawa> In-Reply-To: <78fd90fb-f852-fcc2-303a-3320eff77cf6@linux.ibm.com> References: <20201008155617.19032-1-lukma@denx.de> <20201019135937.176650ab@jawa> <78fd90fb-f852-fcc2-303a-3320eff77cf6@linux.ibm.com> Organization: denx.de X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_//35O7/n6NYwvHQ7.DdT=5rd"; protocol="application/pgp-signature" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" --Sig_//35O7/n6NYwvHQ7.DdT=5rd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 19 Oct 2020 14:48:12 +0200 Stefan Liebler wrote: > On 10/19/20 1:59 PM, Lukasz Majewski wrote: > > Hi Stefan, > > =20 > >> 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: > >> =E2=94=8C=E2=94=80=E2=94=80../nptl/pthread_mutex_timedlock.c > >> =E2=94=82 270 /* Block using the futex. */ > >> =E2=94=82 >271 int err =3D lll_futex_clock_wait_bit= set > >> (&mutex->__data.__lock, =20 > >=20 > > Yes. You are right. The lll_futex_clock_wait_bitset shall be > > converted as well... I must have overlooked it, sorry. > > =20 > >> =E2=94=82 272 oldval, clockid, abstime, > >> =E2=94=82 273 PTHREAD_ROBUST_MUTEX_PSHARED > >> (mutex)); (gdb) where > >> #0 0x7dfb9948 in __pthread_mutex_clocklock_common > >> (mutex=3Dmutex@entry=3D0x406144 , clockid=3Dclockid@entry=3D0, > >> abstime=3Dabstime@entry=3D0x7ddf9290) > >> at ../nptl/pthread_mutex_timedlock.c:271 > >> #1 0x7dfb9c12 in __GI___pthread_mutex_timedlock64 > >> (abstime=3D0x7ddf9290, mutex=3D0x406144 ) at > >> ../nptl/pthread_mutex_timedlock.c:632 #2 __pthread_mutex_timedlock > >> (mutex=3Dmutex@entry=3D0x406144 , > >> abstime=3Dabstime@entry=3D0x7ddf930c) at > >> ../nptl/pthread_mutex_timedlock.c:644 #3 0x004020bc in thr > >> (arg=3D) at ../sysdeps/pthread/tst-robust10.c:33 #4 > >> 0x7dfb6a06 in start_thread (arg=3D0x7ddf9b00) 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 =3D (const struct __timespec64 *) 0x7ddf9290 > >> > >> (gdb) p/x *abstime > >> $9 =3D {tv_sec =3D 0x5f8d597f, tv_nsec =3D 0xd79f074} > >> > >> (gdb) p/x *((struct timespec *) abstime) > >> $10 =3D {tv_sec =3D 0x0, tv_nsec =3D 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=3D0, > >> tv_nsec=3D1603098008}, FUTEX_BITSET_MATCH_ANY) =3D -1 EINVAL (Invalid > >> argument) <0.000006> 10:59:58.611707 futex(0x406144, > >> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2148981693, {tv_sec=3D0, > >> tv_nsec=3D1603098008}, FUTEX_BITSET_MATCH_ANY) =3D -1 EINVAL (Invalid > >> argument) <0.000006> 10:59:58.611724 futex(0x406144, > >> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2148981693, {tv_sec=3D0, > >> tv_nsec=3D1603098008}, FUTEX_BITSET_MATCH_ANY) =3D -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=3D1603099351, tv_nsec=3D0}, FUTEX_BITSET_MATCH_ANY) =3D -1 > >> ETIMEDOUT (Connection timed out) <0.652043> > >> > >> Can you please have a look? > >> =20 > >=20 > > I'm going to prepare and sent fixes ASAP. Big thanks for spotting > > it. =20 > 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. >=20 > 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 --Sig_//35O7/n6NYwvHQ7.DdT=5rd Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl+Nqe4ACgkQAR8vZIA0 zr20GQgAlaP/7zDj+mECrwVDCxNV9CAKAhOfghP2UaYlXddAVp7YlIwEceLdd49T N4C46bminQaLQD5ijwgNdzPVPo8BpP69wuV5rV54oRUxD3eH8uuzcDiD8rUuoBxZ Z8kENDWQrYW2VKHzKUn9+vDOiNMnwM9hcsMEmVr3kNg6a2BHCQ//KRo2SFQcw728 hMQ1fUUdZGzx61LhhUYby/QUv86AY1p85ls7KWRYMYx2+IYa/1Dn9HV/+bxuB+cD hL+bULeVB0BRC5XgMDvwZLfQubRqyCQVIyRvLSSfBRdg8x0GiXQhGEjey9nefTQJ HhHUyAPi5ygSEdJ9cdonSypQDhlk3Q== =CtZC -----END PGP SIGNATURE----- --Sig_//35O7/n6NYwvHQ7.DdT=5rd--