From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by sourceware.org (Postfix) with ESMTPS id AC58F3858D39 for ; Tue, 8 Nov 2022 13:27:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AC58F3858D39 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 6AC4C5C0039; Tue, 8 Nov 2022 08:27:45 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Tue, 08 Nov 2022 08:27:45 -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=1667914065; x=1668000465; bh=rY1uzbuGa9 HIuVdeCmVGLhJlNtcZazsd1cHaSKqEoKg=; b=XpzvdxAvhpt+9yHsModGw+jza/ Hw01rXBHHTf5El21Di8AUgSKwLZc2gsgLk/ZT98ixRMkUImTge7NbgqOQuIhSOke XaRZfvgwUCx5RTQtK62vmzlM1u4ScSqK4f4UzKWv83sWaB2wjUWgqf16VdyYErrK u21sJ/NnoyUbAvRKEPm+wWXOy5pUFRgaI6J8VPVGjBED6UrzVBBScaKpymu4fN2q Y0HnOQ3Nt0jItXBJxMnOUPdHD599ZtSE3+bO9hhTFxLzMM4XHjtpr0LiUWYhtXfs fVzp23IL3Iv+IyG9b+CPmU8hrS1fO3710Npd8ZHOTIM8KRK7ddUKR8Su7Ukw== 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=1667914065; x=1668000465; bh=rY1uzbuGa9HIuVdeCmVGLhJlNtcZ azsd1cHaSKqEoKg=; b=QUUSwOfT4e2JsEqvkq4mStIbUsBFmOf09K8Nl07SrBc0 BMyAgUXm9FVBGEup1tRojKz8JWLm4DDctwEseiaO3TeZQdv6WNceC8HF302cIox9 ZNYcsXihMinJSW41un+oqOAiS3l77hCkyKzHSoBJpILh7gBMmX+ZNEapBovcnKUS zi6lEL97OZV8Yrz/UVzSQdyezo2y4+ZCVj2nEJXp56uHZeX4wsjxgWohKmAD1V8d ki8Rdl3svsTuMuaZDGEHjJqSoW4/PPcghbBtTpnfRzs9A67ax6znHOAzOW913xWI yTDr8b72AODEhH0Hd+LJbDc5vSda+1hh0oUovNJJMw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9B454B60086; Tue, 8 Nov 2022 08:27:44 -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: In-Reply-To: <0e823c53-a93f-8ecf-6e83-84b1b78057c8@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> Date: Tue, 08 Nov 2022 14:27:12 +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-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,RCVD_IN_DNSWL_LOW,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 13:51, Adhemerval Zanella Netto wrote: > On 08/11/22 09:28, Arnd Bergmann wrote: > > Sigh, I have added the use of 64 bit syscall if required for some > sysmbols because I assumed that 32 bit time_t syscall would be always > available. This is small optimization to avoid issuing a lot of > 64 bit syscall, specially for syscall like futex. > > But if kernel does indeed assume that COMPAT_32BIT_TIME is a supported > configuration I think we will need to roll out the optimization and > always issue the 64 bit time_t syscalls anyway. From a glibc point of > view it should not matter much besides some small overhead for newer > glibc running on older kernels (we might add a global to disable the > 64-bit call if kernel does not support, as we do for some specific > syscalls). It's possible that I have misread what glibc does at the moment, as I see there are checks for __ASSUME_TIME64_SYSCALLS in the same code path. To clarify: I think an important configuration is one where an embedded system assumes both kernel and userspace are always modern and only support time64. This means CONFIG_COMPAT_32BIT_TIME is disabled in the kernel, and glibc is built to only support a modern enough kernel to assume time64 support is always available. I have not tested whether this works at the moment, but it probably does not require a large rework if there is something still missing. Sorry for having hijacked this thread if this is already supported. If glibc is configured to support older linux-3.2 and includes the time32 fallbacks for that, it's not unreasonable to require CONFIG_COMPAT_32BIT_TIME=y for those. It would be good to document this dependency, or even have an early runtime check similar to the "kernel too old" error that glibc produces when there is a version mismatch. Arnd