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 1497C3858C52 for ; Tue, 8 Nov 2022 10:39:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1497C3858C52 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 E934A5C0203; Tue, 8 Nov 2022 05:39:47 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Tue, 08 Nov 2022 05:39:47 -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=1667903987; x=1667990387; bh=PwQ5zntXTI ntKQqxrSM3t3Gw5+a2uykgQHZpM4l4IR4=; b=jMhGYV4yhLghY/gvfp6SY/xcB2 6mr0uLRUCdy7FelOb13DFDI+/OP6XNK3xwMOoMi99RHt5QpxAYrBBku8naajC9Yi /+3fIovCS06X1Kc7qQOM8Gd2Ke2z0DzhdaJqiNPp5uXEMQ/7Nx2oZB0Vt7DES1Zw u8Nc6nN4yhDTlVaGp8UofV31iegiRi4NrmZlZXuqVHtzRqB9VPx169Xjd78uxA5F Lf5tulo1s2CUlLbxILDpUKbI6K1utHgABI3jCF0ELlHCghN+DkcS1rQ6J9Lzl1y0 yPvphNIDk6KcIj6xleLRwUA3yTlVGXMeL3ox44jooZk6UsGtfJp7/1ZJbaUA== 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=1667903987; x=1667990387; bh=PwQ5zntXTIntKQqxrSM3t3Gw5+a2 uykgQHZpM4l4IR4=; b=pV+7p7QSVZRQ5cBvo3zqjJeRWBwa/ILzrW1kT9KSFcIa 0Msk8ashWdHC9rJxMgEfGiFlJ07YnsbHkoH53oa3HrfGinClUwxrvE8K1mwpJCQU dhcuDlIELPnU4ucN7IcUuVrFz0RuGaWQJycEE/WFUNnV7kQPh5FmyLD8Q5z706s+ GL+6t1zRiEOydC7tBbxenTTmWORKPMSnvWM4cP8BzgzpPc5xntc9OrR6CJle+i6v kyXUfBkG+fqwmINeaqOLr8igcEIPGYWioLq3RQanluoVFlxf79fJjOmU6/G1f+fz bwd/rBwmmnYn3bHBfnyeCEXJ986NZHZLQqEL34TZqQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id C83C5B60086; Tue, 8 Nov 2022 05:39:46 -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: <652b5ea3-2305-4a1e-b1b5-de81864a844c@app.fastmail.com> In-Reply-To: <20221108044945.2173509-1-yunqiang.su@cipunited.com> References: <20221104013913.1543593-1-yunqiang.su@cipunited.com> <20221108044945.2173509-1-yunqiang.su@cipunited.com> Date: Tue, 08 Nov 2022 11:39:26 +0100 From: "Arnd Bergmann" To: "YunQiang Su" , "Xi Ruoyao" Cc: 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.9 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 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. I think for the syscall wrappers implementing the time64 interfaces, there should not be any in_time_t_range() check, but instead they can just call the time64 syscall first and only fall back to the time32 version if that fails with ENOSYS on pre-5.1 kernels. As a side-effect that would also make it slightly faster on modern kernels (skipping the pointless range check), at the cost of being a bit slower on old kernels that require the fallback. Arnd