From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by sourceware.org (Postfix) with ESMTPS id 2F1C93858C78 for ; Mon, 7 Nov 2022 18:25:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2F1C93858C78 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.west.internal (Postfix) with ESMTP id 649043200996; Mon, 7 Nov 2022 13:25:13 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Mon, 07 Nov 2022 13:25:13 -0500 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=1667845512; x=1667931912; bh=QKHgncVlIi ItZIj3+ZOhsIBtglEdU4k2Gq8Oz7htHJs=; b=ikH9rX/jJgF/Jw1UF28ktgS4JS GugAz51w3L0P+OLXxQq5pSVBrjzsOIT4uOwiCY+m9t4hwKqx2uYt4A4qf/me+bMF KANCyp+ZTRdcNwThpk8WeTo0RAwtvo0XknuzcgJKoTPTtkBRqPYECFgzvYXxJtOT T9Jj9Bc0zKgad6EzRjKDateUis4cRT3wWW3UPzGO5b/8PHbU4xvIp4OruHBBg6Cf m807LxLYpjcjq3ZB8IF0ov3ILq89uUK4pk4xP/Jr/w60dn1EgWoyRoBSCYROPZ4z XqkcrnSCmCSRZQKdOi+AewAGkuULqcLW91lIanjKXQC0ujUSoy3csD0ffjgA== 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= fm1; t=1667845512; x=1667931912; bh=QKHgncVlIiItZIj3+ZOhsIBtglEd U4k2Gq8Oz7htHJs=; b=X2Y3Tr43vMWke7A+Fm2bSZXcpSGUWi9D3AUOLugXjdQ9 ONhynOfdMJe6s6vJmooa2vOV2ANl+DYHTObtI8Jjtsir4Ha8hu7H6KyZWlFPHAuq PN6eKbrCgukWaVAAqfRi/FGlQX77kt82a8+Q2kFbuUeG3H7xM2fJt/tsWn4VLY8c PW5jxudG4VdvGwBShfk16pKLbBdFH9Bh0MKjagG86jyqzLeDAXgOcqm1bXdPPD4g gnR3QYCcVioX8g7y/yTWs5CIeBootxXERCAChIBG3xLa3TIK1kdUT+F4YIJ8osZa hfg0k9qV0u7+bnbzGZybIGv9KiA7PMOQSvjXRFR/xQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrvdekgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2FC8CB60086; Mon, 7 Nov 2022 13:25:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: <6100f772-fab4-4e92-a6a9-cf882954df9d@app.fastmail.com> In-Reply-To: References: <20221104015428.1545677-1-yunqiang.su@cipunited.com> <50e745fa-0508-43f1-bd0a-cfa789239f7e@app.fastmail.com> Date: Mon, 07 Nov 2022 19:24:58 +0100 From: "Arnd Bergmann" To: "Adhemerval Zanella Netto" , "YunQiang Su" , "Xi Ruoyao" Cc: syq@debian.org, aurelien@aurel32.net, "Jiaxun Yang" , "Maciej W. Rozycki" Subject: Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 Content-Type: text/plain X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Nov 7, 2022, at 19:08, Adhemerval Zanella Netto wrote: > On 04/11/22 07:02, Arnd Bergmann wrote: > In fact it was reported as an y2106 problem some time ago [1] and we > fixed on 2.34 [2]. And I give that STAT_HAS_TIME32 is not entirely > clear, since for glibc perspective is has multiple stat definitions. I think we need to coordinate this when we change the kernel to add truncation of the 64-bit time values. It sounds like glibc does an 'unsigned int' to 'long long' conversion for the legacy stat syscall, rather than a conversion from a signed value, and it would be helpful to have a matching interpretation between kernel and glibc. What is the glibc behavior for i386 with 64-bit time_t on a kernel without statx? Does that also intepret a time value of -1u as a 2106 timestamp, or does it convert that into a 1969 timestamp like the other (not mips/pa-risc) 64-bit architectures do? Arnd