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.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 1BC061F910 for ; Mon, 7 Nov 2022 18:08:55 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="X7/+WKXm"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0761E385840E for ; Mon, 7 Nov 2022 18:08:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0761E385840E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667844527; bh=VSQhqjJ61y+FiyecIxWSZqoGKJ5Lrvomp+NduPZKRt4=; 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=X7/+WKXmQ88my5oqWIrEWRjJtOdQA72z9xra4kVtCwSFZklzFWBsqv1d9VVk5SZ0D gITIVplymFKuSAFXbGMfTDnsrkOSXJzWpYPK1ESxvUUwWlFNSYxZpszDs7D2P2zCfN zIH7A2Jv/i7ijp+gVrntpZHpJm2aqZe1k5Z1cHK4= Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id ED4B33858D3C for ; Mon, 7 Nov 2022 18:08:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED4B33858D3C Received: by mail-oi1-x230.google.com with SMTP id m204so13000476oib.6 for ; Mon, 07 Nov 2022 10:08:25 -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=VSQhqjJ61y+FiyecIxWSZqoGKJ5Lrvomp+NduPZKRt4=; b=4+748VfndBfyLIE1yFIw+niNQ6pbfQB0tbZzUbfJQ8cKWZj5eSvpv9HjVpl2xQMOZe crJq+jdEHcPZhVW5O+TIHLITg95SGP8jhIoCWi5c9pr6IFiLYubDYSZBPvx/OmTcq68O jCWr2F4iMO53kQh447S9qX9dU+eexHpfHC+BnMX3eOYvXEGzX+U2KEcaYf1yGm4nWUvN eG01aw5qj/iULE83o2WlJdiCgEPzJPlHeny584NdTt+PCKSjwHZSeVwe9IYWPsgA8cKC QZyp/BDelN86SPtG2JsLyDp++xA+gjZbV2ertB/6BM0rDNdxg7q6medsvI9lY2uAjSW+ TFsQ== X-Gm-Message-State: ACrzQf3qrOJQqrcsw/Tm/Wo6hgUCrL8mRqnM6iUXWcp7eBp0K5uXmycO d3Yfe4t9CqAR3WVR/nw/LagrEw== X-Google-Smtp-Source: AMsMyM7pbQhkWTZnt1NoVhmlUOpha6wyk00mRBOB/duAy/rTzBsGAmm3/vsYbmi1Gbn4+I/Dc1Rwag== X-Received: by 2002:a05:6808:1706:b0:351:8703:2271 with SMTP id bc6-20020a056808170600b0035187032271mr37352056oib.76.1667844505218; Mon, 07 Nov 2022 10:08:25 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:a9f4:fc60:ae8f:c4b6:cf0a? ([2804:1b3:a7c0:a9f4:fc60:ae8f:c4b6:cf0a]) by smtp.gmail.com with ESMTPSA id h25-20020a056870171900b0013d9bd4ad2esm3412094oae.12.2022.11.07.10.08.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Nov 2022 10:08:24 -0800 (PST) Message-ID: Date: Mon, 7 Nov 2022 15:08:22 -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] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 Content-Language: en-US To: Arnd Bergmann , YunQiang Su , Xi Ruoyao Cc: syq@debian.org, aurelien@aurel32.net, Jiaxun Yang , "Maciej W. Rozycki" References: <20221104015428.1545677-1-yunqiang.su@cipunited.com> <50e745fa-0508-43f1-bd0a-cfa789239f7e@app.fastmail.com> Organization: Linaro In-Reply-To: <50e745fa-0508-43f1-bd0a-cfa789239f7e@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 04/11/22 07:02, Arnd Bergmann wrote: > On Fri, Nov 4, 2022, at 02:54, YunQiang Su wrote: >> The macro name STAT_HAS_TIME32 is not so clear. >> >> This macro is used for some arch like MIPSn64. >> The kernel_stat/kernel_stat64 of it has a 32bit unsigned time value. >> Thus that has y2106 problem. >> So we should statx to solve this problem. > > I was surprised that you identified this as a y2106 problem > rather than a y2038 problem, so I took a closer look at how this > is handled in the kernel. I found a few interesting bits, in > no particular order: > > - mips-n64 does not have a 'stat64' interface, the kernel > only provides the 'stat', which has the same layout as > the n32 and o32 'stat64'. From the kernel perspective, > using KERNEL_STAT64_HAS_TIME32 seems like a misnomer, > but it's possible that glibc just names things differently > here. > > - parisc64 has the same problem by only exposing a 32-bit > timestamp in stat, but unlike mips, it has both 'stat' > and 'stat64' interfaces, with both using the same layout > as the corresponding parisc32 syscalls. All other 64-bit > architectures have a 'stat' interface with 64-bit > timestamps, on alpha and sparc64 there is also a stat64 > interface because the 'stat' version is limited in > other ways. > > - There is a mix of signed and unsigned types in the > asm/stat.h headers, and you correctly identified mips64 > as using an unsigned type (hence the y2106 limit), > however mips32 is one of the ones using a signed field, > and the kernel does not behave any different and > just relies on gcc's -fno-strict-overflow to truncate > a 64-bit time64_t into a 32-bit signed or unsigned > type either way. > > - When I worked on the original time64 support for the > kernel, I'm sure we had discussed truncating the values > to the correct range on the stat interfaces, but this > has evidently never happened. We should probably add > such truncation, but we would have to decide whether to > truncate this to range of the declared type or more > sensibly to the range of the traditional time_t type. > > - Note that common file systems like xfs and ext3 > intentionally store filesystem timestamps as 'signed' > for compatibility with 32-bit user space, so there > is precedent for interpreting the values as signed > on 64-bit architectures when the range is limited. > > Arnd In fact it was reported as an y2106 problem some time ago [1] and we fixed on 2.34 [2]. And I give that STAT_HAS_TIME32 is not entirely clear, since for glibc perspective is has multiple stat definitions. And I agree with Arnd here, KERNEL_STAT_HAS_TIME32 would be more clear (and glibc side it does have the kernel stat as kernel_stat). It is good to have some confirmation that only mips has this issue, for hppa we follow the current legacy 32 bit to use statx and ony fallback if kernel is not present. [1] https://sourceware.org/pipermail/libc-alpha/2021-March/123753.html [2] https://sourceware.org/git/?p=glibc.git;a=commit;h=5b980d4809913088729982865188b754939bcd39