From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by sourceware.org (Postfix) with ESMTPS id 3F4593858C2B for ; Tue, 8 Nov 2022 11:34:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F4593858C2B 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 EE2D65C00A4; Tue, 8 Nov 2022 06:34:05 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Tue, 08 Nov 2022 06:34:05 -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=1667907245; x=1667993645; bh=En6Zz/muys XKIcFbDDzkndWkZ5Mmq0CxdOmOfX9dueI=; b=YlkKZy9Q7koEvxiampLrG5fmoY 8enbazXyk+sKqwJu8JTyTVszl0a/A5EkKADR+EmK8itio21z7H9ooYQCRJuzVW2o v8ipt5o6Em+wMKxiPpyD+9OQyT3S2YWeHesQGakinSLhjSkvPrilgMvrBBN9safi 0t6qRGWzscM/6yXlkMNS05HLlvC6ruKL9WzOvMzyRZPgYDHEC7YtMJoFlkWS0z2a sDCnelvauTZicXbcjLTbzNjyyEWbrpkAefBDofN9LerpKT5fXq/TSFnDr+0ak2Bl oMG3u99NGk494x8M7zlv9VyPiXj6OYOl4z47oZCOT7yxpziOmU28gbGZ/+bQ== 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=1667907245; x=1667993645; bh=En6Zz/muysXKIcFbDDzkndWkZ5Mm q0CxdOmOfX9dueI=; b=OnPujo3eXSJll8B9kd3z46P6fy1zd4iX1/1/OdEqSmY0 WqR5L2leU+Fa7DBgF6G6BFRON8Jj92QSstObib7IOu1Hhuzhs2eu+1myvRR7gWXW gg1aE7g0LnRCTE/0xlOXKrqos1WiS9IjvvkewLfAGx+YZxFBBAtevSrzK6kD3T3j F9f/AtPWmAznbWrO5Mk9gV/FlS208tKZqOcRRo2nCg+MEJ8UC3sDMoOxkTkYzp20 liZPOf2rMeFPot9uPqLf59qKaV6/uRQBkdL+1r2hNNTNQD7LEiQQevz+qhVKjylY /EZ5K5UBbf+c+MsWE/pXPgaSOWnCPcCSn8q5KY41Pw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 90A51B60089; Tue, 8 Nov 2022 06:34:05 -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: <80f469a6-f432-419d-9cdc-91f2366639d3@app.fastmail.com> In-Reply-To: <87cz9xk84v.fsf@oldenburg.str.redhat.com> References: <20221104013913.1543593-1-yunqiang.su@cipunited.com> <20221108044945.2173509-1-yunqiang.su@cipunited.com> <652b5ea3-2305-4a1e-b1b5-de81864a844c@app.fastmail.com> <87cz9xk84v.fsf@oldenburg.str.redhat.com> Date: Tue, 08 Nov 2022 12:33:45 +0100 From: "Arnd Bergmann" To: "Florian Weimer" Cc: "YunQiang Su" , "Xi Ruoyao" , aurelien@aurel32.net, "Adhemerval Zanella Netto" , "Jiaxun Yang" , "Maciej W. Rozycki" , syq@debian.org Subject: Re: [PATCH v3] Define in_int32_t_range to check if the 64 bit time_t syscall should be used Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham 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 Tue, Nov 8, 2022, at 12:17, Florian Weimer wrote: > * Arnd Bergmann: >> On Tue, Nov 8, 2022, at 05:49, YunQiang Su wrote: >>> Currently glibc uses in_time_t_range to detects time_t overflow, >>> and if it occurs fallbacks to 64 bit syscall version. >>> >>> The function name is confusing because internally time_t might be >>> either 32 bits or 64 bits (depending on __TIMESIZE). >>> >>> This patch refactors the in_time_t_range by replacing it with >>> in_int32_t_range for the case to check if the 64 bit time_t syscall >>> should be used. >>> >>> The in_time_t range is used to detect overflow of the >>> syscall return value. >> >> It looks like the fallback logic has another flaw, I don't >> see how this works on kernels with COMPAT_32BIT_TIME disabled, >> as these only have the time64 syscalls available. > > Isn't that an invalid kernel configuration? No, this is what we will use anyway after 2038 (possibly earlier), so the option is useful to ensure that all userspace has been converted away from the time32 interfaces. Arnd