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.3 required=3.0 tests=AWL,BAD_ENC_HEADER,BAYES_00, BODY_8BITS,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 4BB651F462 for ; Sat, 25 May 2019 16:20:06 +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=w5xm2 kaqcmH9z9G8CV8srufbqUXhymEb7v2wpZPEVkQO49xpFPtF3zEoERVR7umqCyYRs E4hPmB046fFG8XJTVuOf+ucUhed18aQXU63Rl8DjRGNliGcnxQUqrCTNMpPJUKok 73NubmT80yQK9dmoJaU2zxAGDjRB0opxM3eckw= 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=SEt2AlF2lzW TCA0WevowhwJv4ig=; b=OQmBFxYvcDDDnLSvRdOfO2MUbFnNFApk12nDyVUQbuc jpUzxBTFq4+KSSjKKWrtFPfaiF7/8CpZBSCXg1WpVe5df7WbmpCHM6mZA+lSO/xr FQBC5IEtvhIMSteVUww2tbvnYkAEoDvjFZjcbpX5fGT11xp4LecR83RpLXG25WMg = Received: (qmail 73167 invoked by alias); 25 May 2019 16:20:03 -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 73159 invoked by uid 89); 25 May 2019 16:20:03 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Sat, 25 May 2019 18:19:48 +0200 From: Lukasz Majewski To: Stepan Golosunov Cc: libc-alpha@sourceware.org, Arnd Bergmann , Paul Eggert , Joseph Myers Subject: Re: [PATCH v5] y2038: Introduce __ASSUME_TIME64_SYSCALLS define Message-ID: <20190525181948.7647f31a@jawa> In-Reply-To: <20190523113530.6b4a3c60@jawa> References: <20190414220841.20243-1-lukma@denx.de> <20190515142723.20182-1-lukma@denx.de> <20190523073448.2kf5wwrhf3iqlyty@sghpc.golosunov.pp.ru> <20190523113530.6b4a3c60@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/eYuQXVMqHO6aOKhTK3g+f3T"; protocol="application/pgp-signature" --Sig_/eYuQXVMqHO6aOKhTK3g+f3T Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Stepan, Joseph, > Hi Stepan, >=20 > > 15.05.2019 =D0=B2 16:27:23 +0200 Lukasz Majewski =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0=D0=BB: =20 > > > This define indicates if the Linux kernel (5.1+) provides syscalls > > > supporting 64 bit versions of struct timespec and timeval. > > >=20 > > > For architectures with __WORDSIZE=3D=3D64 and __TIMESIZE=3D=3D64 (e.g. > > > x86_64, aarch64) this flag is never defined (as those already use > > > 64 bit versions of struct timespec and timeval). > > >=20 > > > The __ASSUME_TIME64_SYSCALLS shall be only defined on systems with > > > __WORDSIZE=3D=3D32. > > >=20 > > > For x32 this flag is explicitly undefined as this architecture has > > > __WORDSIZE=3D=3D32 with __TIMESIZE=3D=3D64. Despite having __WORDSIZE= =3D=3D32 > > > the x32 has support for 64 bit time values and hence needs to > > > undefine __ASSUME_TIME64_SYSCALLS flag. =20 > >=20 > > What is not clear is how architectures where syscalls like > > clock_settime are already using 64-bit time_t are supposed to be > > identified. Last patch for clock_settime seems to be using > >=20 > > #if __WORDSIZE !=3D 32 || !defined __NR_clock_settime64 && defined > > __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE =3D=3D 64 > > =20 >=20 > The check has been taken from: > sysdeps/unix/sysv/linux/bits/statvfs.h (line 24). >=20 >=20 > Considering your above comment - we would need to introduce two > flags: >=20 > 1. New, glibc global - __ARCH_HAVE_TIME64_SYSCALLS (other names > possible: __ARCH_SUPPORT_TIME64_SYSCALLS, __ARCH_TIME64_SUPPORT) >=20 > #if (__WORDSIZE =3D=3D 32 \ > && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE =3D=3D 32)) > #define __ARCH_HAVE_TIME64_SYSCALLS > #endif I would provide more verbose description of course, but in short the __ARCH_HAVE_TIME64_SYSCALLS would indicate all the archs (with __WORDSIZE =3D=3D 32) which would have a chance to have support for 64 bit time. >=20 > 2. __ASSUME_TIME64_SYSCALLS as it is in this patch (to indicate > kernel support after 5.1+). >=20 >=20 > The __clock_settime64() pseudo code: >=20 > ... > tv_nsec check > ... >=20 > #if __ARCH_HAVE_TIME64_SYSCALLS > # ifdef __NR_clock_settime64 > int ret =3D INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp); > # ifdef __ASSUME_TIME64_SYSCALLS > return ret; > # else > if (ret =3D=3D 0 || errno !=3D ENOSYS) > return ret; > # endif > # endif > if (! in_time_t_range (tp->tv_sec)) > { > __set_errno (EOVERFLOW); > return -1; > } =20 > struct timespec ts32; > valid_timespec64_to_timespec (tp, &ts32); > return INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32); > #else > /* x32, x86_64 */ > return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp); > #endif What do you think about this idea? >=20 > > to select code for these architectures. > >=20 > > This seems too complicated and potentially buggy. Why not just > > define __ASSUME_TIME64_SYSCALLS for this case too and then use > >=20 > > #if defined __ASSUME_TIME64_SYSCALLS && !defined > > __NR_clock_settime64=20 >=20 > As fair as I understood the __ASSUME_TIME64_SYSCALLS was supposed to > indicate in-kernel support for syscalls (similar to __ASSUME_STATX) - > which would result in simpler execution paths.=20 >=20 > > ? > >=20 > > Especially given that in most cases the only difference in resulting > > code with __ASSUME_TIME64_SYSCALLS defined would be the name of the > > constant used (__NR_clock_settime64 when it's defined, > > __NR_clock_settime otherwise). =20 >=20 > And also the case where __clock_settime64() is called from > __clock_settime(). >=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_/eYuQXVMqHO6aOKhTK3g+f3T Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlzpayQACgkQAR8vZIA0 zr2Kbwf+KUoSNJ9GIGjQ39ZeS0cWLs2Ne08oIsQbZ3imgmvb/0i1XM/PYK2oBd3q nHyh6RwTsM9zyRWVR1VIqm+fXdQ5Z3fZJEWSoWqAAZt7HwKNHC7nhy2ysULDrem+ XwlDrUYlP+PckXEzGMnI1TmaTIgQmCm29jy89XUzaqMVxnqSYUuRMhwy1lUE2F75 grQo8TWyzYT2hFIKxxWUhajGVnh0Dldj3E4pADnqETH8CsAKOqhGZGMWxteJNupO uOdVrAFbYIWXtL6o6iUeZ0IPzCGzV86ELP6c4RWcfqdi51SyO9A4BUGDuuMNIDVY Qu61R4FsUItgpYgpSp8g27qz6xZn2g== =5ZDP -----END PGP SIGNATURE----- --Sig_/eYuQXVMqHO6aOKhTK3g+f3T--