Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1834996yba; Sat, 27 Apr 2019 08:07:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqxMpuTMFaeqMs6w8033BFJKGCSSwPLw/pJvNJ6/8ydsKYAjIBK5xxKo7lhTlUaOo8j8XbPg X-Received: by 2002:a62:e411:: with SMTP id r17mr8007862pfh.127.1556377647052; Sat, 27 Apr 2019 08:07:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556377647; cv=none; d=google.com; s=arc-20160816; b=sJyJuRsI2pPzhNurI8Q0yeoOor7J5H+m9pM+HlcKroAo1xRr3IVhmZzF6lohBCjmZT 0hm1xH6LybaYfBOYmOhcpampBPeSyy85c2lCWLMW/6hNO+qysKY5adUP+19miBhzupMd 1VmaSXnHnRhWy+ZNFE4PtcvWi2tP5B65+Ooj40MHBg8kHt6VpCqUhjA/e2vca4mhVcKk 6J5NHZzCnEx5iFMHqT/uajDwAR6hZvN2BydHg/DDC5YVBN0VUklo2reKGcNCiYN7hzTo pgfKFRlWTjjO5V0TEdC2xmSlt2od66dK+3gOcSEVhCMmCPFO6yJ9qEiEHglwjHZDz/KA ai8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date; bh=RvUu/OrbjtrEwcw0gZwalfSxOr8Ff1KUwN25dm84PNA=; b=grV7OyG46hkO0EGEF4t6sdRJkXraf9AQWpG3swpsd0bCu1YrNw+NKx9B/bWkLRT8PA 3zRxe5kN3v0tSJm2WkX/UvGUS1lptWtQSRznZsXR4/tkt4m5PregoymFlrkKIQXD81e8 179+fEZUI1hyZx7w4v5tsIP5oLgsCvg0VK1NNUPLSpcwwc5TXDQaNB5P0lUFESZvrIPL jlSpBsmP5jbNjUc68tecK9Q5Tv0XAzumjI0dlNcFlzuLVKdfC0V8pnXXL5vdYrc7Bch3 +1CnCClYEhDZFNo98OSfCyRQWQaKvHidiAYM2T9eBMw2rL7YGh1Snuj946eVHfzTdzuS LtoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m19si27614723pgk.76.2019.04.27.08.07.11; Sat, 27 Apr 2019 08:07:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726485AbfD0PGW (ORCPT + 99 others); Sat, 27 Apr 2019 11:06:22 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:59158 "EHLO mail-out.m-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725983AbfD0PGV (ORCPT ); Sat, 27 Apr 2019 11:06:21 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 44rvQ10dTgz1r8jy; Sat, 27 Apr 2019 17:06:17 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 44rvQ06xdPz1qtTg; Sat, 27 Apr 2019 17:06:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id fYzmDCfuSyJM; Sat, 27 Apr 2019 17:06:14 +0200 (CEST) X-Auth-Info: im1sM+BrNF0XQIc9Cns2TVCrD+UiqIBfy2GaPzYqT1I= Received: from jawa (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Sat, 27 Apr 2019 17:06:14 +0200 (CEST) Date: Sat, 27 Apr 2019 17:06:13 +0200 From: Lukasz Majewski To: Stepan Golosunov Cc: Arnd Bergmann , Thomas Gleixner , Joseph Myers , libc-alpha@sourceware.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Deepa Dinamani Subject: Re: [PATCH 1/2] y2038: make CONFIG_64BIT_TIME unconditional Message-ID: <20190427170613.38bdfbbd@jawa> In-Reply-To: <20190427095418.344yoomf5nwznatd@sghpc.golosunov.pp.ru> References: <20190426142531.1378357-1-arnd@arndb.de> <20190427004653.3cecd1cb@jawa> <20190427095418.344yoomf5nwznatd@sghpc.golosunov.pp.ru> Organization: denx.de X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/NtOXQs_YE8e+5oiZUS+hS8k"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Sig_/NtOXQs_YE8e+5oiZUS+hS8k Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stepan, > 27.04.2019 =D0=B2 00:46:53 +0200 Lukasz Majewski =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: > > Hi Arnd, > > =20 > > > As Stepan Golosunov points out, we made a small mistake in the > > > get_timespec64() function in the kernel. It was originally added > > > under the assumption that CONFIG_64BIT_TIME would get enabled on > > > all 32-bit and 64-bit architectures, but when I did the > > > conversion, I only turned it on for 32-bit ones. > > >=20 > > > The effect is that the get_timespec64() function never clears the > > > upper half of the tv_nsec field for 32-bit tasks in compat mode. > > > Clearing this is required for POSIX compliant behavior of > > > functions that pass a 'timespec' structure with a 64-bit tv_sec > > > and a 32-bit tv_nsec, plus uninitialized padding. =20 >=20 > > At least for my setup (32bit ARM with 64 bit time support) this > > patch is not fixing anything. =20 >=20 > The patch is not supposed to fix anything on 32-bit architectures as > in-kernel struct timespec64 has 32-bit tv_nsec there. Thus truncation > should happen automatically. I also missed that fact when I was > reading get_timespec64 code. Yes. You are right. The tv_nsec is 32 bit. >=20 > (I am wondering whether such trucation is undefined behaviour in C According to [1] - Chapter 6.3.1.3 - Point 3 it is implementation-defined. > and > whether there should be sign-extension instead of zeroing-out for the > in_compat_syscall() case though.) What I've found is that "typically" the high order bits are discarded. However, it is still "implementation dependent". >=20 > > > The easiest fix for linux-5.1 is to just make the Kconfig symbol > > > unconditional, as it was originally intended. As a follow-up, > > > we should remove any #ifdef CONFIG_64BIT_TIME completely. > > >=20 > > > Link: > > > https://lore.kernel.org/lkml/20190422090710.bmxdhhankurhafxq@sghpc.go= losunov.pp.ru/ > > > Cc: Lukasz Majewski Cc: Stepan Golosunov > > > Signed-off-by: Arnd Bergmann > > > --- > > > Please apply this one as a bugfix for 5.1 > > > --- > > > arch/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > >=20 > > > diff --git a/arch/Kconfig b/arch/Kconfig > > > index 33687dddd86a..9092e0ffe4d3 100644 > > > --- a/arch/Kconfig > > > +++ b/arch/Kconfig > > > @@ -764,7 +764,7 @@ config COMPAT_OLD_SIGACTION > > > bool > > > =20 > > > config 64BIT_TIME > > > - def_bool ARCH_HAS_64BIT_TIME > > > + def_bool y > > > help > > > This should be selected by all architectures that need > > > to support new system calls with a 64-bit time_t. This is > > > relevant on all 32-bit =20 Note: [1] - http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 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_/NtOXQs_YE8e+5oiZUS+hS8k Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlzEb+UACgkQAR8vZIA0 zr2z8gf/Q3cd7NEt3lba9R3Jd4WtSGipupTihng+hzrCulnMN0bI9yi5uaIeHdUM XU07EttxLTCyC1lI+AUCZq2pfds70EcWk4iLDlc8AYFoP7ANhidEIz6IMoDi2kRi UoiCm9PR1HNZyhOgoeJ2CHKhCfcnNii7q9HLdmQss7hwNVPWlrPl62iTDztliy5m CqVNYJT8ATPUxOPveaIZ8STf+bToip/xN6AwrHZLgXYZBeoDHRaJkOC4eI6tgrei n8AWhiFFcTmGHkDQXPpcPVYHOthdQeIupW0afQAArtUDjr/vMINbRakLhkqFcFH6 eZ5TxS6lj+RT/ZkqtY08HY7GyjWhgg== =XsUp -----END PGP SIGNATURE----- --Sig_/NtOXQs_YE8e+5oiZUS+hS8k--