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 127EE3858C39 for ; Tue, 8 Nov 2022 12:28:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 127EE3858C39 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 9D86D5C00EB; Tue, 8 Nov 2022 07:28:44 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Tue, 08 Nov 2022 07:28:44 -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=1667910524; x=1667996924; bh=fJRKVm7WVP eSKmg4sfZ79nDMxFaw9IccvikYUs3N5iE=; b=pEovN6H/hxUAPQ44TGUHJrt8vl XZfMH3rHG3EBu8JTXjXKZcLGp5YO3oDoC5rGkgATfqhQcOE72iL2DkxwgW5mKaNG 0CMNQLtSAJxUOqjNSXJxNZUqaa1YpB83+oIggxKZ37FaAjXhftk+Qq1WXUvJ9yOi I4nt0q4h/t/w4UhrSp80mnBbC7QcIB5guVGNpxHZGGfcWqJSQx1PhbelvOlFrDoz ljrySMrENOVRk+SiJ5PogJyEsYTPT4w97QepgMcgBgo6w2eI7Kn+4fmPtOLPZr+x TAEkrLIv5vv/sF1IB2KgrRfoX01Xz8O8KMbOUhmAJrFdvy151SaQPfCl/2Cg== 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=1667910524; x=1667996924; bh=fJRKVm7WVPeSKmg4sfZ79nDMxFaw 9IccvikYUs3N5iE=; b=diAwd3uPO7SunSb5VN5rnKLeApQxk+6B1Lnb2z7a3R5o m52fqefuScaU+bz6F7qcmiT/9QS1eJ4BJWq3h0a1FgSMyuR+Q1+DcgzGtZbN+NDo 6LUosYsfT7qydQieYSMWVsuF82sRGXimWbkEl8NBjqm4y0vBQfgAN9lb+xHaxyNz y50lxcIxZCbaeZqe4pCGsc8WSjsDvW/GSqmeDrnimQ6MMO6PYpsS6YrDma9XLfxC ghFWmbUNdji585+sDpZA9OQ5dreplhjSAUX0Rh/JihBFHRWoCyWMoLJgGkxVGuoV w8E5IACWrx68oe1PY9KwK/tlL1vOZk1560LRYZ+81Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgdegudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 30AF1B60086; Tue, 8 Nov 2022 07:28:43 -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: <177e1cb4-7952-484c-8838-f3c41c6c1441@app.fastmail.com> In-Reply-To: <87sfitisjq.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> <80f469a6-f432-419d-9cdc-91f2366639d3@app.fastmail.com> <87sfitisjq.fsf@oldenburg.str.redhat.com> Date: Tue, 08 Nov 2022 13:28:17 +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=-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 12:39, Florian Weimer wrote: >> On Tue, Nov 8, 2022, at 12:17, Florian Weimer wrote: >>> * Arnd Bergmann: >>>> On Tue, Nov 8, 2022, at 05:49, YunQiang Su wrote: >>> >>> 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. > > What happened to not breaking userspace? It's a configuration option that makes sense for some users but not others, just like a lot of other conditional system calls that we have (UID16, IPC, SGETMASK_SYSCALL, FUTEX, EVENTPOLL, INOTIFY, IO_URING, AIO, TIMERFD, QUOTA, MODULES). If you turn these compile-time symbols off, you naturally break compatibility with any applications and libraries that call the corresponding syscalls, but nevertheless there are embedded systems that never need to call them and prefer to leave the symbols disabled. If you know you run a modern glibc, you probably don't care about uid16 syscalls or sgetmask/ssetmask and can leave them disabled. Similarly, system calls that have not been used for a long time eventually get removed completely, with extreme caution. Examples include prof(), lock(), afs_syscall(), pkey_set(), or ftime(). uselib() may be next on the list. For embedded systems, being able to turn off the broken time32 interfaces right now is fairly important, otherwise it is excessively hard to validate that a system is not accidentally calling the wrong interfaces or relying on fallbacks that no longer work after 2038. For a desktop distro, that obviously does not apply, as users need to be able to run arbitrary binaries that were built for time32 or uid16. > Those with 32-bit applications will want to run their legacy stuff in a > time-shifted environment, so these system calls must remain supported > outside specialized applications. We have had several discussions about adding time-shifting for CLOCK_REALTIME to the kernel, and always concluded that the added complexity is not worth the possible benefit (unlike shifting CLOCK_MONOTONIC, which has use cases for checkpoint/restart). Clearly one can do the same thing using some LD_PRELOAD library or a virtual machine, but then again if you do this, you can also have that LD_PRELOAD library do the conversion to the time64 interfaces, or have the VM run a kernel with the time32 syscalls still present. Arnd