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.4 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 D4BA51F453 for ; Thu, 2 May 2019 13:56:07 +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=h3xHF DW/E15/GYXxtwJaXYX8AXno6giWZz4kBilBDJYmWSm3+hoIPJ+u0MrjFXjuq4T2q nalI8uEK+5lEWyaM/d66/YrAW3QzvvBhU1wmvDLW/xP9q0mVxfMObUBu3fLqlBAm XKvSu66JOS67FMwD9rU5NQcIk8QfdphAk0SBzY= 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=FdaN1ppxEq3 CIv1lUjq4Z4mj6KQ=; b=RcIHqj9tqO/Y5s0gVHAT43pvmqtgTiVhcCSq9HXK7F1 x7RPNBPB3mAz7AleCplrcmDxhad5QKPIPLeSfEhWE2hHXzFgfhAfXtiWkwRtpmsA 009olRXBgfN6ohxQ5GlgB03xA2WCb9sycRrbN9O0V85gTmCZ/yTKFC3lkOFLnKXA = Received: (qmail 8577 invoked by alias); 2 May 2019 13:56:05 -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 8569 invoked by uid 89); 2 May 2019 13:56:05 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Thu, 2 May 2019 15:55:49 +0200 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: <20190502155549.2f7bf82d@jawa> In-Reply-To: <20190502115459.d3qwvhvmzl6c5kmo@sghpc.golosunov.pp.ru> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/9WlpWKE0Oed.CJlsPTuPbIm"; protocol="application/pgp-signature" --Sig_/9WlpWKE0Oed.CJlsPTuPbIm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stepan, > 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: > > Hi Stepan, > > =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 > > > > 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 > > > I think that __NR_clock_settime64 should be used unconditionally > > > when __ASSUME_64BIT_TIME is defined. =20 > >=20 > > Could you clarify it a bit? =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 > > 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 > The fallback would be wrong in cases where __NR_clock_settime is not > defined or is not 32-bit. >=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 > > > I believe that the only 32-bit architecture without > > > __NR_clock_settime64 is x32. =20 > >=20 > > Ok, I see.=20 > >=20 > > Please correct me - would it be feasible to just #undef > > __ASSYME_TIME64_SYSCALLS for x32 ? =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 > 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 I see. Thanks for the hint. > > > While newer 32-bit architectures like > > > riscv do not have __NR_clock_settime: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co= mmit/?id=3Dd4c08b9776b392e20efc6198ebe1bc8ec1911d9b =20 > >=20 > > Then it shall use clock_settime64 from the outset if support > > added. =20 >=20 > It probably should have __TIMESIZE =3D=3D 64 though. 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_/9WlpWKE0Oed.CJlsPTuPbIm Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlzK9uUACgkQAR8vZIA0 zr2Z1AgAvb9RaeWCPvW4QFCCY0uqZ1QVnd4p9V6cS1JOEE6MkeOBMbzTlvIduWsM VGXEIdVMrY1ITe3ri0xeZzuopwCoM5ORRh0VYml9UgWzXKxQzMkSnKcwCwL26nVd ELUg62nHRJsAqezkZGAQTuzCilQtwt8FDArsSg1gjGyGLnRMP+tEQFQEGVQmf+t3 hox+gG0XD0eZHlxU7UnZHNVy5mwpVcwEZMj3qAEga8giaOf9MB2PHnSf5kbs0OHP EpWew65NWYvlHtpRMi4qS8UdB2Ud5JcEMv3s0ERtE1GKN1dnyhWWXUW81eRLwCJl Ye4FkQH821b/qwxOboojEHSW2NI26A== =bwqp -----END PGP SIGNATURE----- --Sig_/9WlpWKE0Oed.CJlsPTuPbIm--