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=-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 [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 E51411F910 for ; Tue, 8 Nov 2022 13:50:06 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="rOcKqqxx"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2ED3A385843B for ; Tue, 8 Nov 2022 13:50:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2ED3A385843B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667915405; bh=ESCwVMtRh9UvL+aOC7D2CiXJ30CSyLhIFUKPihR0LjA=; 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=rOcKqqxxVFWp7ZwnD//qvNt1A3kiXG6ky09BiZEHQnyGVVJ2esZ5zozsosm/hI731 Var9a9K5XmlTkIDRS7znGdChD7vNBCKbnPkBBVCBE2SnQqa56lhUtguCP5njUnz6J2 B6C3gn0OO0VhhTcr2mQUwTFAbS4cPznLtNHKMVr8= Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id B22333858D39 for ; Tue, 8 Nov 2022 13:49:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B22333858D39 Received: by mail-ot1-x336.google.com with SMTP id cn2-20020a056830658200b0066c74617e3dso8396906otb.2 for ; Tue, 08 Nov 2022 05:49:44 -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=ESCwVMtRh9UvL+aOC7D2CiXJ30CSyLhIFUKPihR0LjA=; b=GbNCJvCBIeYxwk+uVw3bWo0EFCbU074Bc7jEaqpHYTsyFkuh1U5jAeSDrGPEX5evTF GfLXt8UgZkFihZ8Q3slwxBej5rZA8KR6qUHqP1aTrXrYr+cmn+Dlp0ny8kjpZfmfBL15 QiSco+rVKWuHUDmt5QvO/p5ymSq+OW6ckc+HL5NBBbvRNP0N+T0i3acxlsLWyeG0XGeC 5ZW+RiCh1PIym7Vafs/nJteMVOgfqUi9LW+EopVdZfcPWTIvQaEpDMfeUBldu25XiCh2 1oN5qMY1Ki00GdfeJ923oMfnxwDZuJHScg+1STRo3EZWIqOIMg3QV7ZVaGrHDuKMhA/A 5KYg== X-Gm-Message-State: ACrzQf2AWsCbxA7JKMMCiHQLX7N3nhtwdt7s75d+tzgGpfKP47w8Fe3i 2WYNOfteMTpbPzvbsIw4x2r3zV6rxCVE17IW X-Google-Smtp-Source: AMsMyM46PtUq/PfEdGy3KmgijCA30O8KIvGummuHyvg5EE5L+vJPtS1tg8/GdL4tn/PcsQf8zWl40w== X-Received: by 2002:a05:6830:1605:b0:66c:55c2:8780 with SMTP id g5-20020a056830160500b0066c55c28780mr23333108otr.378.1667915383862; Tue, 08 Nov 2022 05:49:43 -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 g81-20020a9d12d7000000b0066c44b4f2d6sm4172827otg.43.2022.11.08.05.49.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Nov 2022 05:49:43 -0800 (PST) Message-ID: <1c812047-6cf0-107d-faa3-70532d5ca0de@linaro.org> Date: Tue, 8 Nov 2022 10:49:40 -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" , YunQiang Su 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> Organization: Linaro In-Reply-To: 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 10:27, Arnd Bergmann wrote: > 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. 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. 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.