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-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B52C71F466 for ; Thu, 16 Jan 2020 13:35:02 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; q=dns; s=default; b=C/+F+ F5xQRgSdUTA9ZLVAjGU7oq52zwNzCyNIrdLbYBvPLd6XMFwYiaKEuP9KEKGZuDxs Uw3O+UaKBzhSoceVM4b5Tu2e5+l6MchAal9jXpy1KTN02+UUfh9KiSXkg4TzWoXa fRW3cnMPaT1FCC5nakcRc1S7aS2+2E3BosF980= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; s=default; bh=ZZoFpktvAer sxIEK98Df/X5PSzQ=; b=Vblgjvh1nC7VW2+pl2DfrNajKkL+IDNs/dSzvWFayRU 01a3bkYXtGtKiN48ZRzlw1Qt6CwXvn518R7mqxPCbxA8cWcBQ4rZbmLJRODVPYaU OVKUNWg1NYcFWQbx760Xa1SkltHONfg6CSnkGfa/do/lyKyqvyzlGkE45WGVKrng = Received: (qmail 68034 invoked by alias); 16 Jan 2020 13:35:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 67974 invoked by uid 89); 16 Jan 2020 13:34:59 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Thu, 16 Jan 2020 14:34:32 +0100 From: Lukasz Majewski To: Alistair Francis , Joseph Myers Cc: Alistair Francis , GNU C Library , Arnd Bergmann , Adhemerval Zanella , Florian Weimer , Palmer Dabbelt , "Maciej W. Rozycki" , Zong Li Subject: Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval Message-ID: <20200116143432.4e5c3010@jawa> In-Reply-To: References: <6fce89fec812352770884a62c6fa158890480e2a.1578824547.git.alistair.francis@wdc.com> <20200114115848.396c6eaf@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/f3a.6uF_1xVFuyHQj/=wr2S"; protocol="application/pgp-signature" --Sig_/f3a.6uF_1xVFuyHQj/=wr2S Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Alistair, Joseph > On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers > wrote: > > > > On Thu, 16 Jan 2020, Alistair Francis wrote: > > =20 > > > > To allow it this syscall wrapper shall be converted (written) > > > > in the same way as e.g: > > > > > > > > ./sysdeps/unix/sysv/linux/clock_settime.c > > > > > > > > (the same issue is with getitimer). > > > > > > > > Then only redirection when __USE_TIME_BITS64 is set are needed > > > > to use __setitimer64/__getitimer64 on Y2038 safe systems. =20 > > > > > > I'm not sure what you mean here. > > > > > > There is no setitimer64/getitimer64 syscall so we need to make > > > sure we pass a 32-bit time_t here. If __TIMESIZE =3D=3D 32 then we > > > don't need any changes and can just directly make the syscall (as > > > we do in this patch). The conversion is only required if > > > __TIMESIZE =3D=3D 64 as we need to convert to/from a 32-bit time_t. = =20 > > > > This is a point about the general structure and goals of the Y2038 > > work. > > > > We want to end up at a point where, on systems where time_t is > > currently 32-bit, you can build with -D_TIME_BITS=3D64 and get 64-bit > > time_t instead. That means that all time-related functions, > > including getitimer and setitimer, will, on such systems, need to > > have two implementations in glibc, one using 64-bit times and one > > using 32-bit times. =20 >=20 > I'm still confused. If we build with -D_TIME_BITS=3D64 does that then > mean that __TIMESIZE =3D=3D 64 ? >=20 > In which case the user exposed time_t is 64-bit and these calls will > take a 64-bit time_t and convert it to/from a 32-bit time_t to pass to > the kernel. The user will only ever use/see a 64-bit time_t. >=20 > > > > The implementation structure generally being used is that the main > > implementation has an interface using 64-bit times (even if it ends > > up using syscalls with 32-bit times) and the one using 32-bit times > > is a thin =20 >=20 > Isn't that what is happening here when __TIMESIZE =3D=3D 64 ? >=20 > > wrapper around it (if time_t is already 64-bit, the second > > implementation does not exist and some macros ensure the first > > implementation keeps its existing name). Once all functions have > > been moved to that structure, we can set things up so that all > > those 64-bit functions are exported from glibc and add _TIME_BITS > > support in the headers. =20 >=20 > Ah, do you mean that glibc should expose a 64-bit time_t version if > __TIMESIZE =3D=3D 32? Yes, exactly. Currently 32 bit ARM (__WORDSIZE =3D=3D 32 && __TIMESIZE =3D=3D 32) use 32 = bit time_t. However, after compiling the source code with -D_TIME_BITS=3D64 the time_t will become 64 bit. Please find example setup for tests_y2038: https://github.com/lmajewski/y2038-tests/blob/master/Makefile#L25 (Two binaries are build from the same sources - one is Y2038 safe and other is not). The notable difference between the new RV32 port and existing ARM32 is that for new ports (i.e. RV32) the __TIMESIZE =3D 64 is set from the outset. For the latter (ARM32) the __TIMESIZE =3D 32 is kept and IIRC we will NOT update it to __TIMESIZE =3D 64 anytime soon. Instead, in exported headers _TIME_BITS=3D64 will be set by default (approach similar to the one for _FILE_OFFSET_BITS=3D64). Joseph, am I right? > So even __TIMESIZE =3D=3D 32 systems can call a 64-bit > time_t version (even if the syscall ends up being 32-bit). +1 Please find example conversion code for timespec_get conversion: https://patchwork.ozlabs.org/patch/1224222/ it internally uses __clock_gettime64, which uses 64 bit time no matter on which architecture it runs (even with __TIMESIZE=3D=3D32). Please also refer to the branch, which moves 32 bit ports closer to being Y2038 safe: https://github.com/lmajewski/y2038_glibc/commits/glibc_timespec_get-convers= ion-v1 >=20 > Alistair >=20 > > > > -- > > Joseph S. Myers > > joseph@codesourcery.com =20 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_/f3a.6uF_1xVFuyHQj/=wr2S Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl4gZmgACgkQAR8vZIA0 zr0VUAgAv/kqytLNhmOEo4r2P93AvDaXPfkTmGZETyTyLQjTriKsnPPPCEjyW1lr aRcGPq9NehDOtt+SOOsGWG8LiIssckjvZdSyPzSOI6bovn5ZqtPup+it7X47j1r8 mTaZ7MLhPRI7J7vE/kHVbibKFuQ+Xcc93UC7FxuTij+8suf8QtCnS2uEHFnSJsrq GVg4/HOMm2T1tAXXXr60rsY+mOgT8Oe8Po0tFXYVdZ4NL0DGEIsWz5y1/UIbqL+7 bZXsJ4UHbI6SmsSQJnMBOSuea8p8P2JwuhFV0AxN2ITBQpVawz30oDb3Km92lXd8 qQcRutSXBLsLUNUdkQRFlS5jlwqYig== =eaBr -----END PGP SIGNATURE----- --Sig_/f3a.6uF_1xVFuyHQj/=wr2S--