From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by sourceware.org (Postfix) with ESMTPS id 4F44F3858D37 for ; Tue, 14 Jul 2020 07:56:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4F44F3858D37 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 4B5XsD1xZFz1qsbS; Tue, 14 Jul 2020 09:56:32 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4B5XsD08j2z1qwTJ; Tue, 14 Jul 2020 09:56:32 +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 GcGUC-voYb6T; Tue, 14 Jul 2020 09:56:27 +0200 (CEST) X-Auth-Info: NBkrTItL/VeI2JcxuAHnpYwFzXbxko4unc/TxRDEFwc= 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; Tue, 14 Jul 2020 09:56:27 +0200 (CEST) Date: Tue, 14 Jul 2020 09:56:17 +0200 From: Lukasz Majewski To: Adhemerval Zanella Cc: Joseph Myers , Paul Eggert , Alistair Francis , Arnd Bergmann , Alistair Francis , GNU C Library , Florian Weimer , Carlos O'Donell , Stepan Golosunov , Andreas Schwab , Zack Weinberg Subject: Re: [RFC 00/10] y2038: nptl: futex: Provide support for futex_time64 Message-ID: <20200714095617.320eb56d@jawa> In-Reply-To: <8e50e48c-f3e9-7c56-bff7-8da0d80a4bf2@linaro.org> References: <20200707150827.20899-1-lukma@denx.de> <8e50e48c-f3e9-7c56-bff7-8da0d80a4bf2@linaro.org> 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_/FQM2RGDElDxlbTk=I0MOz95"; protocol="application/pgp-signature" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 14 Jul 2020 07:56:37 -0000 --Sig_/FQM2RGDElDxlbTk=I0MOz95 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Adhemerval, > On 07/07/2020 12:08, Lukasz Majewski wrote: > > Please find this early RFC for converting 'futex' syscall based code > > (pthreads/nptl/sem/gai) to support 64 bit time. > > When applicable the futex_time64 syscall is used. > >=20 > > The main purpose of this RFC is to assess if taken approach for > > conversion is correct and acceptable by the glibc community. > >=20 > > Quesitons/issues: > >=20 > > 1. This whole patch set shall be squashed into a single patch, > > otherwise, the glibc will not build between separate commits. I've > > divided it to separate patches on the purpose - to facilitate > > review. =20 >=20 > Another possibility could to work by adjusting each symbol and the > required futex_* / lll_lock machinery instead. For instance, add > 64-bit time_t support pthread_mutex_{timed,clock}lock, which in turn > required to adjust > futex_lock_pi/lll_futex_timed_wait/lll_futex_clock_wait_bitset. I've looked for such possibility, but the real issue IMHO is the need to convert struct timespec to struct __timespec64 in functions definitions/declarations. In the end you would need to convert lll_futex_syscall() which need to support __ASSUME_TIME64_SYSCALLS and futex_time64. After this you are forced to convert all other pthread syscalls, which use timeout argument. >=20 > In this way we can tests the change better since they are incremental. Please see above comment - lowlevellock-futex.h written with C preprocessor macros is the real issue here. >=20 > >=20 > > 2. Question about rewritting lll_* macros in lowlevel-*.h - I'm > > wondering if there is maybe a better way to do it. Please pay > > attention to the *_4 suffix. =20 >=20 > For lll_* I really think we should convert them to proper inline > function instead, the required code change to adjust the macro is > becoming really convoluted.=20 I fully agree here - the code as proposed[1] - is rather not clean and safe. > I can help you on refactoring to code so > the time64 changes should be simpler. Ok. Thanks. Now for instance we do have: __pthread_mutex_clocklock_common (funcion) (pthread_mutex_timedlock.c) | \|/ lll_timedwait (macro) __lll_clocklock | | \|/ \|/ __lll_clocklock_wait -> eligible for "conversion" Y2038 (function!) lll_futex_timed_wait -> (macro) lll_futex_syscall -> here is the call to futex syscall (macro) The code itself has many levels with inline functions convoluted with macros. >=20 > Also, futex is a syscall used extensively and I think we should > optimize the fallback code to avoid issue the 64-bit time one if the > kernel does not support it (as we do for clock_gettime). I think that this is not the case for most systems. The 64 bit call for futex_time64 (and other 64 bit syscalls) were introduced in Linux 5.1 - which is now more than a year ago. The newest LTS Linux (5.4) now supports it - so it is likely that new BSPs will use it. Especially, yocto LTS - dunfell (3.1) supports by default 5.4 kernel. >=20 > I have send a patchset with some y2038 fixes and I added a generic > support to simplify it [1]. We will probably need some adjustments to > make it work on libpthread. >=20 I will share my comments on it in the patch itself. > [1] https://sourceware.org/pipermail/libc-alpha/2020-July/116259.html >=20 > >=20 > > 3. What would be the best point in the glibc release cycle to apply > > this patch set as it convets the core functionality of the library? > >=20 > > Just after the stable release? =20 >=20 > I think it is late for 2.32, we should postpone it to 2.33.=20 I'm fine with postponing it as long as some work will be done in parallel - the futex system call is crucial in many parts of glibc library. Sooner we convert it and pull patches into glibc master, then sooner it matures. Links: [1] -https://patchwork.ozlabs.org/project/glibc/patch/20200707150827.20899-4-lu= kma@denx.de/ 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_/FQM2RGDElDxlbTk=I0MOz95 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl8NZSEACgkQAR8vZIA0 zr0/4QgAiLudAVx5GEPBxfTfCo4p2AoJu/1021jgVctHjsGgIgvoGb2AfIG0TjdR hJf721A57g1umt/KvBgpK6wZ1DMyF445T53BUZNL1FQEOifPRSjqaSG443rXi8uq J5161VC60cOYjPvoxy3WbGqTH4D5L3Bm4IQbd1Skb+qNaXS6CUcp6AaJOPXRNoTi EgSegP4TPB2gozjcbsq9inPn402/2aRY5cXLUEnlZ1uddh9/bmV1XBXx2SrvWSKj rdi1j3RXzGsmEeGBCbvE6JYYsSsaybLvZdjCasSdMpQCHQB/xEtDGoGd6jnOIukk Q/spKbXud8XvbF88bZzMZYSz8Au7OA== =Xrmp -----END PGP SIGNATURE----- --Sig_/FQM2RGDElDxlbTk=I0MOz95--