From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9370 invoked by alias); 6 May 2019 14:27:13 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 9362 invoked by uid 89); 6 May 2019 14:27:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,GARBLED_BODY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 spammy=till, H*r:192.168.8, proposition X-HELO: mail-out.m-online.net Date: Mon, 06 May 2019 14:27:00 -0000 From: Lukasz Majewski To: Stepan Golosunov Cc: Joseph Myers , libc-alpha@sourceware.org, Arnd Bergmann , Paul Eggert Subject: Re: [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define Message-ID: <20190506162659.6d7e4a59@jawa> In-Reply-To: <20190506153844.77cad546@jawa> References: <20190414220841.20243-1-lukma@denx.de> <20190429104613.16209-1-lukma@denx.de> <20190429104613.16209-3-lukma@denx.de> <20190430110505.2a0c7d1a@jawa> <20190430214748.rzjlcu3f3hdyqnhw@sghpc.golosunov.pp.ru> <20190502105108.541fe118@jawa> <20190502115459.d3qwvhvmzl6c5kmo@sghpc.golosunov.pp.ru> <20190502155549.2f7bf82d@jawa> <20190506153844.77cad546@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/LF4yTHJIyar4.t3mLTWzarI"; protocol="application/pgp-signature" X-SW-Source: 2019-05/txt/msg00076.txt.bz2 --Sig_/LF4yTHJIyar4.t3mLTWzarI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-length: 5426 Hi Stepan, > Hi Stepan, >=20 > > Hi Stepan, > >=20=20=20 > > > 02.05.2019 =D0=B2 10:51:08 +0200 Lukasz Majewski =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0=D0=BB:=20=20=20=20 > > > > Hi Stepan, > > > >=20=20=20=20=20=20=20 > > > > > 30.04.2019 =D0=B2 11:05:05 +0200 Lukasz Majewski =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BB:=20=20=20=20=20=20 > > > > > > IMHO, the abstraction would be: > > > > > >=20 > > > > > > 1. The __ASSUME_64BIT_TIME is _never_ defined for 64 bit > > > > > > native systems > > > > > >=20 > > > > > > 2. It is defined by default in: > > > > > > sysdeps/unix/sysv/linux/kernel-features.h for 32 bit systems > > > > > > (and the actual presence of the syscall is decided upon > > > > > > definitions of __NR_xxx* (i.e. # ifdef > > > > > > __NR_clock_settime64).=20=20=20=20=20=20=20=20 > > > > >=20 > > > > > I think that __NR_clock_settime64 should be used > > > > > unconditionally when __ASSUME_64BIT_TIME is defined.=20=20=20=20= =20=20 > > > >=20 > > > > Could you clarify it a bit?=20=20=20=20=20=20 > > >=20 > > > I meant something like this: > > >=20 > > > int > > > __clock_settime64 (clockid_t clock_id, const struct __timespec64 > > > *tp) { > > > #ifdef __ASSUME_64BIT_TIME > > > return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp); > > > #else > > > =E2=80=A6 > > >=20 > > > But I see now that most of the existing code would just miscompile > > > in cases where __ASSUME_* is defined while corresponding __NR_* is > > > not.=20=20=20 > > > > In the code as proposed in: > > > > https://patchwork.ozlabs.org/patch/1092583/ > > > >=20 > > > > The call to clock_settime64 is protected with # ifdef > > > > __NR_clock_settime64 - otherwise we do a fallback to (32 bit) > > > > clock_settime. > > > >=20 > > > > Moreover, the # ifdef __ASSUME_64BIT_TIME provides a fallback > > > > path if kernel version is older than 5.1.=20=20=20=20=20=20 > > >=20 > > > The fallback would be wrong in cases where __NR_clock_settime is > > > not defined or is not 32-bit. > > >=20=20=20=20=20 > > > > > > As those syscalls are provided on almost every 32 bit system > > > > > > now (5.1-rc6): > > > > > > git grep -n "clock_settime64" > > > > > >=20 > > > > > > gives support for: arm, arm64 (compat mode), m68k, > > > > > > microblaze, mips, parisc, powerpc, s390, sh, sparc, x86, > > > > > > xtensa > > > > > >=20 > > > > > > So it would be reasonable to just add this __ASSUME > > > > > > definition code to > > > > > > sysdeps/unix/sysv/linux/kernel-features.h and #undef it for > > > > > > architectures not supporting it (i.e. c-sky and > > > > > > riscv).=20=20=20=20=20=20=20=20 > > > > >=20 > > > > > I believe that the only 32-bit architecture without > > > > > __NR_clock_settime64 is x32.=20=20=20=20=20=20=20 > > > >=20 > > > > Ok, I see.=20 > > > >=20 > > > > Please correct me - would it be feasible to just #undef > > > > __ASSYME_TIME64_SYSCALLS for x32 ?=20=20=20=20=20=20 > > >=20 > > > You'll need to know whether to use __NR_clock_settime64 or > > > __NR_clock_settime in cases where __TIMESIZE =3D=3D 64 and > > > __WORDSIZE =3D=3D 32.=20=20 >=20 > Please correct me, but I do have some doubts here. >=20 > As x32 now uses 64 bit time (and has TIMESIZE=3D=3D64) - it uses the > clock_settime call (with in-kernel broken tv_nsec padding clearing - > but for this the fix is in its way to upstream). >=20 > Why does it need to also support clock_settime64 ?=20 I was too eager to send the mail. It is connected with your proposition to use __WORDSIZE for #ifdef on __ASSUME_TIME64_SYSCALLS.=20 As x32 has __WORDSIZE=3D32 (but __TIMESIZE=3D64), it would fall into "category" of archs using explicit 64 bit calls (i.e. clock_settime64). However, for it - those shall be replaced with syscalls used up till now (i.e. clock_settime). Am I right here ? >=20 > > >=20 > > > One way would be by defining __ASSUME_TIME64_SYSCALLS > > > unconditionally on x32 and then defining __NR_clock_settime64 to > > > __NR_clock_settime when __ASSUME_TIME64_SYSCALLS is defined while > > > __NR_clock_settime64 isn't. > > >=20=20=20=20=20 > >=20 > > I see. Thanks for the hint. > >=20=20=20 > > > > > While newer 32-bit architectures like > > > > > riscv do not have __NR_clock_settime: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi= t/commit/?id=3Dd4c08b9776b392e20efc6198ebe1bc8ec1911d9b=20=20=20=20=20=20 > > > >=20 > > > > Then it shall use clock_settime64 from the outset if support > > > > added.=20=20=20=20=20=20 > > >=20 > > > It probably should have __TIMESIZE =3D=3D 64 though.=20=20=20=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=20=20 >=20 >=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_/LF4yTHJIyar4.t3mLTWzarI Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature Content-length: 488 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlzQRDMACgkQAR8vZIA0 zr3E2wf9E2qNqeycuCE7FCI+T39FfoEphlFuFeekTWYmcW0jb+qwSM+OgfK7Bq3A Ev9UN32M5qNa/R7SSfZLBei1MwODlp532VMY8GvM/93q82nnw6ywp3cWx4+P9E1D m8zLo9IlTlBq84OO6jxW27CobBb43hZbDaxiqZqVuVHB/WnoeK2Ssi6Ftp1ZdhbN uMRT6NA1WewQhXQbY8Qzg6ujpzUwpN53JRs7R4ggLo2q2Xw8Bk6vEw40sy0+4p25 zgCYd0BBT88oSD2HEO4dmPGN1mrGVsn84hhU36irlwp4WvS1sITdCfsYs42zv85r ntJr2dEqNWjWlw1B4nKv/YpZzcRsKw== =olUL -----END PGP SIGNATURE----- --Sig_/LF4yTHJIyar4.t3mLTWzarI--