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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7CCC61F910 for ; Fri, 4 Nov 2022 10:03:51 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=arndb.de header.i=@arndb.de header.b="gjXMpETp"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="io1tVZ/b"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F0FCF385695E for ; Fri, 4 Nov 2022 10:03:35 +0000 (GMT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by sourceware.org (Postfix) with ESMTPS id CED733858029 for ; Fri, 4 Nov 2022 10:03:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CED733858029 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arndb.de Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AECD45C0055; Fri, 4 Nov 2022 06:03:00 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Fri, 04 Nov 2022 06:03:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1667556180; x=1667642580; bh=WHm9pdgkpr kMEM5OVWXxjBnFH3DNN0znqjE6XUqKxBM=; b=gjXMpETpU4tjUV181MQjSCx1xe qcWSjPZyMTafY5/kNoDNGh6bkhaj4T5UbG7iSl+QSoRYQoLfmTLus0UsE5Wzp34r NFboNIk4c0HleH2HKyyPjT8wHwZ9USiLjcZBS903JGkhI56HNEwLRGYQzmJGv25L cBg9qh/E/tf10mw/RBiuBx9A+6VJsP6Q9bUMGrkilTjztgsO6UeerxnwGG/ySWU7 PZw5cGVB+vJufbpGgQxuM3EnH3RtnVOQlSwxDsz8lZmnmSgJ9DcSboizN9kicP+w sOLw17HnZgVsAdIxdX64FDlUxXK5A3omC7KsXXXNAMRz9RSIULb+uPKAf0+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1667556180; x=1667642580; bh=WHm9pdgkprkMEM5OVWXxjBnFH3DN N0znqjE6XUqKxBM=; b=io1tVZ/bf+L+JqL1gtlL6snZTKkMUZvC58jWX3VvzDb9 mUNslAPVUnNYMV6/qfVa8HSef9kquv3kQrXbr3PatPHO+zL/GNAPKhwvErmcZYji uDBJHTDEeWgvPPMB14Z/muMjkkR3P+PUF2ynQUvcjVY+okbVohaT+o+PqjcfZ/it yT7P+grV4Dj+LcN3HQITUB9KTTfixWf8oOdqqF8anQfpXWj0H98f7+K1MAASumPG pBtY+lqs3SZuWEIsxYt6Ravo/THI8NFcZ/uJSmBtWxSFRJFg2rN/mCyFEHbjbian l2/bnCr+pRvzF8xPhjEDbzYyoO+CWzvKivYGPtF/1Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrvddugddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id EA83DB603ED; Fri, 4 Nov 2022 06:02:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1087-g968661d8e1-fm-20221021.001-g968661d8 Mime-Version: 1.0 Message-Id: <50e745fa-0508-43f1-bd0a-cfa789239f7e@app.fastmail.com> In-Reply-To: <20221104015428.1545677-1-yunqiang.su@cipunited.com> References: <20221104015428.1545677-1-yunqiang.su@cipunited.com> Date: Fri, 04 Nov 2022 11:02:41 +0100 From: "Arnd Bergmann" To: "YunQiang Su" , "Xi Ruoyao" Subject: Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 Content-Type: text/plain X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: syq@debian.org, aurelien@aurel32.net, Jiaxun Yang , "Maciej W. Rozycki" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Fri, Nov 4, 2022, at 02:54, YunQiang Su wrote: > The macro name STAT_HAS_TIME32 is not so clear. > > This macro is used for some arch like MIPSn64. > The kernel_stat/kernel_stat64 of it has a 32bit unsigned time value. > Thus that has y2106 problem. > So we should statx to solve this problem. I was surprised that you identified this as a y2106 problem rather than a y2038 problem, so I took a closer look at how this is handled in the kernel. I found a few interesting bits, in no particular order: - mips-n64 does not have a 'stat64' interface, the kernel only provides the 'stat', which has the same layout as the n32 and o32 'stat64'. From the kernel perspective, using KERNEL_STAT64_HAS_TIME32 seems like a misnomer, but it's possible that glibc just names things differently here. - parisc64 has the same problem by only exposing a 32-bit timestamp in stat, but unlike mips, it has both 'stat' and 'stat64' interfaces, with both using the same layout as the corresponding parisc32 syscalls. All other 64-bit architectures have a 'stat' interface with 64-bit timestamps, on alpha and sparc64 there is also a stat64 interface because the 'stat' version is limited in other ways. - There is a mix of signed and unsigned types in the asm/stat.h headers, and you correctly identified mips64 as using an unsigned type (hence the y2106 limit), however mips32 is one of the ones using a signed field, and the kernel does not behave any different and just relies on gcc's -fno-strict-overflow to truncate a 64-bit time64_t into a 32-bit signed or unsigned type either way. - When I worked on the original time64 support for the kernel, I'm sure we had discussed truncating the values to the correct range on the stat interfaces, but this has evidently never happened. We should probably add such truncation, but we would have to decide whether to truncate this to range of the declared type or more sensibly to the range of the traditional time_t type. - Note that common file systems like xfs and ext3 intentionally store filesystem timestamps as 'signed' for compatibility with 32-bit user space, so there is precedent for interpreting the values as signed on 64-bit architectures when the range is limited. Arnd