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.5 required=3.0 tests=AWL,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 5BDA11F910 for ; Tue, 8 Nov 2022 14:08:10 +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="lmbNpr37"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="Gd37qHu0"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8E0F53858435 for ; Tue, 8 Nov 2022 14:08:09 +0000 (GMT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by sourceware.org (Postfix) with ESMTPS id 259573858403 for ; Tue, 8 Nov 2022 14:07:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 259573858403 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 7E8125C00E8; Tue, 8 Nov 2022 09:07:50 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Tue, 08 Nov 2022 09:07:50 -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=1667916470; x=1668002870; bh=IIrDyybQRW kP8WQiCVPB18wKiH2eL+hkJtP1asOz3+Q=; b=lmbNpr37ozMftYuy3D4CSO13Kr ikvQ1XZ2EDRcZ6l5ApgwlhHePKgD8wNUXcYHpt24j80/1X9bXlEL468NrhLorD1r KCR8V/2lyZ8Bl+TXBSdU+vz259ezn6//h6H7s7ZzQU+78HiU4ljRvy+uVaDe8o7l U1zjChn0xDnwfgJHyfodeyj0TCAthuZbNZh+Mdcu3WrkBw+f06K4WXSF1GGLuzil bgpyErneVtaeqTL6q+3OGUYX8fioP1Qc53HMWvEx7yGEOMErR9QD7LBLR62JoMk5 +o1GJBN7wJMoaOgThKAg3IAYUkPq/bdsIFzJx3/Yj7cCcy8cWbnBZ+cGTxlA== 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=1667916470; x=1668002870; bh=IIrDyybQRWkP8WQiCVPB18wKiH2e L+hkJtP1asOz3+Q=; b=Gd37qHu0p4O3enfIVKVQiRGK/E0sfiYHgHU+mOrEIFTC rzugKSuah4eD1YFFx9xndEh4PsX4LdlOnP+m23khlWmDW0G/rW5GGxuJFfNdsP2D q5+7+jOTd/x63uhTqDJDBUZ4i/TV1y/s4zwThWiIm/IbHN7WFQPf0shyb+OgLZyA 23L1/rOaEH4biGt4HAxt6Bd7NlvZaXPERihxOai6dXLdowh6yopbtx2sBKxl4Xei OltrIz69Vw0PpSh6lXI9aCS626l5m2cQmhvNUC6Pgy8cXrNJ3LNb25dM90Smix/x RfZIAmEXU6azWsJb6n/Vlza435dVmBpvm/3okk4qCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3C770B60086; Tue, 8 Nov 2022 09:07:49 -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: <5c46fff4-ed17-4043-946f-efed9a07755c@app.fastmail.com> In-Reply-To: <1c812047-6cf0-107d-faa3-70532d5ca0de@linaro.org> 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> <80f469a6-f432-419d-9cdc-91f2366639d3@app.fastmail.com> <87sfitisjq.fsf@oldenburg.str.redhat.com> <177e1cb4-7952-484c-8838-f3c41c6c1441@app.fastmail.com> <0e823c53-a93f-8ecf-6e83-84b1b78057c8@linaro.org> <1c812047-6cf0-107d-faa3-70532d5ca0de@linaro.org> Date: Tue, 08 Nov 2022 15:07:26 +0100 From: "Arnd Bergmann" To: "Adhemerval Zanella Netto" , "Florian Weimer" Cc: "YunQiang Su" , "Xi Ruoyao" , aurelien@aurel32.net, "Jiaxun Yang" , "Maciej W. Rozycki" , "YunQiang Su" 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-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: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Tue, Nov 8, 2022, at 14:49, Adhemerval Zanella Netto wrote: > On 08/11/22 10:27, Arnd Bergmann wrote: > > Yes, the 32 bit fallback assumes that you either use the default minimum > kernel or configure with --enable-kernel with a value lower than 5.1. > And the optimization such as ecf2661281c was added on the basis that for > such configuration the 32 time_t is always present. > > For __ASSUME_TIME64_SYSCALLS (default fro 64 bit time_t ABI and for 32 > bit time_t with --enable-kernel=5.1) the 32 bit syscall should not be > issued. Ok, good. What is the amount of testing that this combination (--enable-kernel=5.1, CONFIG_COMPAT_32_BIT_TIME=n) has seen? Is this something that is already part of some regression test setup, or rather something that is supposed to work but isn't in widespread use? > There are still the issue for a default configured glibc when running > on kernels with CONFIG_COMPAT_32BIT_TIME=y, this would require to remove > the fallback optimizations for !__ASSUME_TIME64_SYSCALLS. You mean CONFIG_COMPAT_32BIT_TIME=n with !__ASSUME_TIME64_SYSCALLS, right? As I said, I'm not too worried about this corner case, as long as there is some kind of use feedback that tells users to change either glibc or kernel configuration. My impression is that the optimizing for running on old kernels is not overly helpful, and that changing the fallback logic would be better, but this does not feel like a correctness issue when general-purpose distros always enable CONFIG_COMPAT_32BIT_TIME, and embedded users that want it disabled always build a matching glibc as well. Arnd