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.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 00B091F910 for ; Tue, 8 Nov 2022 23:29:47 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 789803858009 for ; Tue, 8 Nov 2022 23:29:44 +0000 (GMT) Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 0CE353858C39 for ; Tue, 8 Nov 2022 23:29:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0CE353858C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org Date: Tue, 8 Nov 2022 18:29:32 -0500 From: Rich Felker To: Adhemerval Zanella Netto Cc: Arnd Bergmann , Florian Weimer , 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 Message-ID: <20221108232931.GM30685@brightrain.aerifal.cx> References: <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> <5c46fff4-ed17-4043-946f-efed9a07755c@app.fastmail.com> <3df612e6-d0d5-e2e3-aacf-53f73557c71d@linaro.org> <225bd25f-ac61-4f59-67b5-63105a3a8ea6@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <225bd25f-ac61-4f59-67b5-63105a3a8ea6@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 08, 2022 at 04:47:06PM -0300, Adhemerval Zanella Netto wrote: > > > On 08/11/22 11:27, Adhemerval Zanella Netto wrote: > > > > > > On 08/11/22 11:07, Arnd Bergmann wrote: > >> 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? > > > > I would say not much I am aware off, I usually check only against stock > > kernels from usual distributions (ubuntu, fedora, etc) and our patchwork > > instance also uses default kernels. > > > >> > >>> 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. > > > > I added the optimization mainly because to disable the use of 32 bit > > time_t support requires a configure switch. It is worries me a bit > > the combination of CONFIG_COMPAT_32BIT_TIME=n with > > !__ASSUME_TIME64_SYSCALLS as potential source of obscures bugs, but > > I think that it would be unlikely in future when newer kernels will > > be more present. > > I am ccing Rich because he agrees that CONFIG_COMPAT_32BIT_TIME is a > userspace breakage and it will most likely break musl tim64 support. > He suggested to move this option behind EXPERT [1] and fix the > documentation. It's absolutely a violation of the "don't break userspace" syscall API/ABI stability policy, and *does* break musl. We generally do not use "new" syscalls except when the "old" syscall lacks the functionality needed. Rich