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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, 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 [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 95F3F1F910 for ; Tue, 8 Nov 2022 12:52:27 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="tf1lCusC"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 984F03858422 for ; Tue, 8 Nov 2022 12:52:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 984F03858422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667911943; bh=X2F5ds3qpiFJ8P688ZiT+ucpgDUj1ujZVuI3cb7VuJY=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=tf1lCusCbFQVUpdsEiIcebmtaDZwySVUqabtE0AX4VVI/DzcqcrLC7tIKiRHXXkns niAHIQkiqe8fsehmFXgDfe05T1aX/NlDKDMVenKM6tDfrZlvITwe5ebdkM13n2+vhp u2jxLBp3GroNqqoKfdVbXbsZEXgZc1RzyI92TZ7I= Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) by sourceware.org (Postfix) with ESMTPS id 1CEBE3858C53 for ; Tue, 8 Nov 2022 12:52:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CEBE3858C53 Received: by mail-oo1-xc31.google.com with SMTP id r76-20020a4a374f000000b004988a70de2eso2024188oor.2 for ; Tue, 08 Nov 2022 04:52:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X2F5ds3qpiFJ8P688ZiT+ucpgDUj1ujZVuI3cb7VuJY=; b=b4TY5da5g0bpeZP8rLfXUh/1le1Qbubpy2v9235zt5BQC3pKRVTGywxoA1co7WkekG ndaBkoeLLwF6a/+/3uGXxF0jl342O1XfNMUJZ255DcrnCjHHfwIGT1T+rDVCmPgeMy1L uugG+hNFkwWudyLWS0WkJo4NX9/TSQ70wHEyD5a8zUHq2wMY9gnvaVV2goAzuSGSNfQb 3rIoxm0MQ6fB4Xz96ncgSvghZmxjjet/YaZFyffpm/8KcsNb3EEZtSPmwsbUf45/PL9N N3gtpoFMNxIZ2qIiDZjdwDN1X9WYyADNDGxyx4zH+QX66h3ucietSXJsjh+BN6EVRDI0 r9pA== X-Gm-Message-State: ACrzQf1DOE4L2HdlHbt/gyw/5R5+tQLJjyTz6TTDGV/G+IRpxrAywAoZ CdzB3lrB1s3EdxVL/RUnEJu4oArb3jVkYgSA X-Google-Smtp-Source: AMsMyM7E0EUkIdjiztIW3Wvr7JL8msgNJoTwNHk/72OiAck/QzMEH0SHivt1xFkHncpUd2LNHdbi6w== X-Received: by 2002:a4a:db8e:0:b0:49e:c55e:3333 with SMTP id s14-20020a4adb8e000000b0049ec55e3333mr6747624oou.21.1667911921219; Tue, 08 Nov 2022 04:52:01 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:a9f4:7d29:e035:dbf1:661f? ([2804:1b3:a7c0:a9f4:7d29:e035:dbf1:661f]) by smtp.gmail.com with ESMTPSA id g17-20020a056870d21100b00136cfb02a94sm4534054oac.7.2022.11.08.04.51.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Nov 2022 04:52:00 -0800 (PST) Message-ID: <0e823c53-a93f-8ecf-6e83-84b1b78057c8@linaro.org> Date: Tue, 8 Nov 2022 09:51:57 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH v3] Define in_int32_t_range to check if the 64 bit time_t syscall should be used Content-Language: en-US To: Arnd Bergmann , Florian Weimer Cc: YunQiang Su , Xi Ruoyao , aurelien@aurel32.net, Jiaxun Yang , "Maciej W. Rozycki" , syq@debian.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> Organization: Linaro In-Reply-To: <177e1cb4-7952-484c-8838-f3c41c6c1441@app.fastmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , From: Adhemerval Zanella Netto via Libc-alpha Reply-To: Adhemerval Zanella Netto Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 08/11/22 09:28, Arnd Bergmann wrote: > 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. 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). > >> 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