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,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 5E5441F731 for ; Fri, 9 Aug 2019 07:26:11 +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=uw1lP i5PtUk+OInxhrcPyxWytSqsTzy7aLgV2idk0KBNbA6WHtHj7YeZ2LkYjSQQLP1R8 /Bs8IOXVhx8h470Ed9AUcH6mJdiyOBfhIteSf2eoH8kWanedVQe5vAqqXkV8JOqY a8PryzVuLbHDagi+0ERkLVf6U/HNTb0yzPr0aQ= 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=nknMY7BjrIz EXi2RXjr6/9hlc88=; b=Q2sO99xOMSQsW6y7MBLF8OoRb9Bu1tpzk1a57EOneWu NVDfCfMZ+y/tu+nVEAULHQZy7dC5bt3bjeahnTOYBtvAV1XlU35FhJe8MBdXNps0 hrfj2DNuQ2/4cYE85GCwAmU1J5iJF5hsVTzFDszw/QwDgcg/+GSI5h2vm7gc8WpI = Received: (qmail 111682 invoked by alias); 9 Aug 2019 07:26:08 -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 111674 invoked by uid 89); 9 Aug 2019 07:26:08 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Fri, 9 Aug 2019 09:25:44 +0200 From: Lukasz Majewski To: Zack Weinberg Cc: Joseph Myers , Wolfgang Denk , GNU C Library , Alistair Francis , Alistair Francis , Adhemerval Zanella , Arnd Bergmann Subject: Re: Accelerating Y2038 glibc fixes Message-ID: <20190809092544.615385de@jawa> In-Reply-To: <20190730160430.6b6f302e@jawa> References: <20190712072103.D3DBC24003A@gemini.denx.de> <20190726123902.6f8813da@jawa> <20190730160430.6b6f302e@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/AnT2ie=5uIfh2l7l1+daGeI"; protocol="application/pgp-signature" --Sig_/AnT2ie=5uIfh2l7l1+daGeI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Zack, > Hi Zack, >=20 > > On Fri, Jul 26, 2019 at 6:39 AM Lukasz Majewski > > wrote: ... =20 > > > > > See for example [1] - there are just 7 lines of "code". But > > > > > Joseph does not accept our patches. The arguments he gives > > > > > are not on a technical level; =20 > > ... =20 > > > Our goal is to add a solid foundation for the Y2038 work, so we > > > would know the direction where we are heading. =20 > > ... =20 > > > If you think that it would be better and most of all faster if you > > > rewrite the description, then I don't mind. > > > > > > It would be great if you could do it sooner than latter as this > > > slows down our development. =20 > > ... =20 > > > The most recent version of this patch set (v8): > > > https://patchwork.ozlabs.org/patch/1117100/ =20 > >=20 > > I haven=E2=80=99t been following the details of these patches super > > carefully, and I=E2=80=99m not sure I understand what _Joseph=E2=80=99s= _ concerns > > with your writing is. However, I=E2=80=99m a native English speaker, I= =E2=80=99ve > > read over the text in the patch at > > , I do think I > > understand the issues at a high level, and I do think the meaning > > of __ASSUME_TIME64_SYSCALLS could be explained more clearly. I=E2=80=99m > > prepared to work with you to come up with better wording =20 >=20 > Thanks for offering your help. Shall I provide more input to this issue? >=20 > > but I > > need to ask you a bunch of questions. Could you please reply to > > each of the queries marked Qn below? > >=20 > > As I understand it, we have five distinct cases to consider: > >=20 > > 1. All future LP64 ABIs and all but one existing LP64 ABI, > > identified by __WORDSIZE =3D=3D 64: time_t is already a 64-bit integer > > type and all of the relevant system calls already accept it in that > > form. glibc=E2=80=99s implementation of, for instance, clock_gettime may > > continue to invoke the system call numbered __NR_clock_gettime. =20 >=20 > This is exactly how we shall proceed with machines having > __WORDSIZE=3D=3D64 (e.g. x86_64, armv8, etc). >=20 > They now support 64 bit time with non suffixed syscalls. >=20 > In the patch [1] the __WORDSIZE =3D=3D 64 check covers this. >=20 > >=20 > > 2. The exception to (1) is Alpha. That is an exclusively LP64 > > architecture, but in glibc 2.0 it used 32-bit time_t, and we > > still have compatibility code for that case. The compatibility > > symbols invoke a set of compatibility syscalls with =E2=80=98osf=E2=80= =99 in their > > names: for instance, gettimeofday@GLIBC_2.0 invokes > > __NR_osf_gettimeofday. Not all of the time-related functions in > > glibc have compatibility symbols, only those that existed in > > version 2.0. > >=20 > > Your patches do not touch this compatibility code at all, as far > > as I can see. =20 >=20 > Yes, you are correct. I was not even aware of such a case (as I found > Alpha as 64 bit arch when I did my checking). >=20 > > Alpha being out of production, and binaries compiled > > against glibc 2.0 being rare anyway, it would only make sense to > > involve this code in your patches if it reduced the overall > > volume of compatibility code somehow, but regardless we need to > > make sure it doesn't break. =20 >=20 > As you mentioned - we shall not break existing binaries. However, I'm > not sure if we shall spent more time/effort on the arch being near EOL > (or at least being out of production now). >=20 > >=20 > > 3. x32 (recently new 32-bit ABI for x86): like case 1, time_t is > > already 64-bit and we use unsuffixed system calls. The text says > > this case is identified by __WORDSIZE =3D=3D 32 && __TIMESIZE =3D=3D= 64, > > but the code actually checks __SYSCALL_WORDSIZE. > >=20 > > Q1: Which condition correctly identifies this case, __TIMESIZE =3D=3D > > 64 or __SYSCALL_WORDSIZE =3D=3D 64? =20 >=20 > It is: >=20 > (__WORDSIZE =3D=3D 32) && ((defined __SYSCALL_WORDSIZE > &&__SYSCALL_WORDSIZE =3D=3D 64)) >=20 > Only x32 defines the __SYSCALL_WORDSIZE =3D=3D 64 (as it has __WORDSIZE = =3D=3D > 32, but supports 64 bit syscalls ABI). >=20 > >=20 > > Q2: Could we perhaps ensure that __TIMESIZE and/or > > __SYSCALL_WORDSIZE is defined to 64 whenever __WORDSIZE =3D=3D 64? Then > > we could collapse this into case 1. =20 >=20 > __TIMESIZE =3D=3D 64 for x32.=20 >=20 > The x32 uses the same set of syscalls (e.g. clock_gettime) as in > point 1 (as for example x86_64). >=20 > >=20 > > 4. Brand-new (added in kernel 5.1 or later) 32-bit ABIs: time_t will > > always be 64-bit, =20 >=20 > This would be true after we make the "switch" to support Y2038 aware > systems. Please find example implementation [2] from this patch series > [3] (it adds example code for converting __clock_settime to support 64 > bit time when __ASSUME_TIME64_SYSCALLS is defined). >=20 > > _but_ glibc=E2=80=99s implementation of time-related APIs > > may need to invoke system calls with suffixed names: > > clock_gettime invoking __NR_clock_gettime64, for instance. Also, > > the kernel will not provide all of the time-related system calls > > that have historically existed; glibc must, for instance, implement > > gettimeofday in terms of clock_gettime. =20 >=20 > Yes, correct. Some syscalls would be emulated (as they are not or will > not be converted to 64 bit version). >=20 > >=20 > > Q3: What macros are defined for this case? =20 >=20 > There are no macros yet available. >=20 > >=20 > > Q4: Does glibc need to call system calls with suffixed names in > > this case? =20 >=20 > I think yes - for example the gettimeofday would internally use > clock_gettime64 (vDSO if available). >=20 > >=20 > > Q4a: If the answer to Q4 is =E2=80=98yes=E2=80=99, why is that, and = can we change > > the kernel so that it=E2=80=99s the same as x32 and the LP64 > > architectures? =20 >=20 > We need new set of syscalls for 64 bit time support on 32 bit archs > (WORDSIZE=3D=3D32); for example x32/LP64 would still use clock_settime > syscall (number X). To have the same functionality (64 bit time > support) 32 bit archs would need to use clock_settime64 (number 404 on > armv7) >=20 > And here the __ASSUME_TIME64_SYSCALLS comes into play. If the arch is > capable of providing 64 bit time, (no matter if it uses clock_settime > or clock_settime64), then __ASSUME_TIME64_SYSCALLS is defined. >=20 > It is also assumed that both clock_settime64 and clock_settime provide > the same ABI, so no code needs to be adjusted in glibc. >=20 > If code needs to be adjusted (as the calls are not compatible) - a new > flag will be introduced (like with semtimedop) >=20 > > (Either by removing the suffixes, or by _adding_ suffixed aliases > > to asm/unistd.h for x32 and LP64 architectures.) =20 >=20 > Wouldn't this caused the ABI break? >=20 > >=20 > > 5. Historical 32-bit ABIs, where the existing set of system calls > > takes 32-bit time_t, and Linux 5.1 added a matching set that > > takes 64-bit time_t. For compatibility with old programs that make > > direct system calls, the kernel will not rename the __NR_ > > constants for the old (32-bit) system calls; instead new constants > > with =E2=80=9864=E2=80=99 or =E2=80=98time64=E2=80=99 suffixes will be = added. As in case 4, the > > new set of system calls does not cover all of the historic > > time-related system calls. > >=20 > > In this case, and only this case, glibc=E2=80=99s code needs to acco= unt > > for the possibility that the new __NR_ constants are not defined > > (because glibc is being compiled against kernel headers from a > > version older than 5.1), or that the new system calls are not > > available at runtime (glibc was compiled against new kernel > > headers but is running with an old kernel). > >=20 > > The #if is complicated enough that I=E2=80=99m not sure, but I _thin= k_ > > your code only defines __ASSUME_TIME64_SYSCALLS when the new > > constants are _guaranteed_ to be defined. > >=20 > > Q5: Is it correct that __ASSUME_TIME64_SYSCALLS is only defined > > when the new constants are guaranteed to be defined? =20 >=20 > No. >=20 > The __ASSUME_TIME64_SYSCALLS is defined only when the architecture > supports 64 bit time related ABI. >=20 > (either via clock_settime on e.g. x86_64/arm64 or clock_settime64 on > arm). >=20 > Please consult the code for clock_settime [4]. It shows how the > __ASSUME_TIME64_SYSCALLS flag is used in practice. >=20 > >=20 > > Q6: All of the other __ASSUME_ constants mean both that we assume > > the kernel headers are new enough to provide all the necessary > > declarations, and that we assume the feature is available at > > runtime: no fallback code will be included in the library. Is > > this also the intended meaning of __ASSUME_TIME64_SYSCALLS? =20 >=20 > The patch [1] defines the __ASSUME_TIME64_SYSCALLS as the ability of > the architecture (via kernel syscalls) to provide 64 bit time support. >=20 > As shown in [4] - the fallback code is called when > __ASSUME_TIME64_SYSCALLS is NOT defined and if architecture doesn't > support clock_settime64. >=20 > >=20 > > zw =20 >=20 >=20 > Note: >=20 > [1] - https://patchwork.ozlabs.org/patch/1117100/=20 >=20 > [2] - > https://github.com/lmajewski/y2038_glibc/commit/3d5f3512438de7426acba58c1= edf53f756f8570b#diff-c051022b496f12bd9028edb46b8ec04d >=20 > [3] - > https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-__clock= -internal-struct-timespec-v6 >=20 > [4] - > https://github.com/lmajewski/y2038_glibc/commit/69f842a8519ca13ed11fab0ff= 1bcc6fa1a524192 >=20 >=20 >=20 > Best regards, >=20 > Lukasz Majewski >=20 > -- >=20 > 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 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_/AnT2ie=5uIfh2l7l1+daGeI Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl1NH/gACgkQAR8vZIA0 zr2k8AgA0gQAm6ZBI+K2ardhwst26kNIMlKmPbcYtfso5Ha2D7mTt6kbMmfwnxNd lzzJYj9U7Pob+WGDcB6YbAbCjn0FB+0RdFhTAxjRd51ovMe5Ifwmk/oGiw5QWkd2 fuDMSZTm+ZsTjPO+Z3GSzHSOpbtcROSajba1yZ4s40ESHqoQRevYMtkLiIcHYlC/ lEV7ABnXcT29REvvDCjhrJyYuMTRT9fniPpouCQH6pxi80mOABt7T5ppPBosGo3T 4CaV9rwAF5Z8QibyCnDy1mXpdS886U1Fflsaljyuz6UzHCj/I1vn36srt0gtqJOi wgNrvTZS79/1yGTy25qeeQzotEyOlA== =eEh+ -----END PGP SIGNATURE----- --Sig_/AnT2ie=5uIfh2l7l1+daGeI--