From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>,
YunQiang Su <yunqiang.su@cipunited.com>,
Xi Ruoyao <libc-alpha@sourceware.org>
Cc: syq@debian.org, aurelien@aurel32.net,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
"Maciej W. Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32
Date: Tue, 8 Nov 2022 09:04:24 -0300 [thread overview]
Message-ID: <9ccb6d5c-e054-29cd-06ce-04ef5ee312b8@linaro.org> (raw)
In-Reply-To: <5ae33887-9a56-482f-b8b3-c223ad2959ee@app.fastmail.com>
On 08/11/22 08:21, Arnd Bergmann wrote:
> On Mon, Nov 7, 2022, at 19:45, Adhemerval Zanella Netto wrote:
>> On 07/11/22 15:24, Arnd Bergmann wrote:
>
>>> What is the glibc behavior for i386 with 64-bit time_t on a
>>> kernel without statx? Does that also intepret a time value
>>> of -1u as a 2106 timestamp, or does it convert that into a
>>> 1969 timestamp like the other (not mips/pa-risc) 64-bit
>>> architectures do?
>>
>> The time_t for glibc is always signed and for legacy 32-bit ABIs
>> it issues fstatat64 and assumes that kernel will handle potential
>> overflow by returning a proper error (if syscall succeeds then the
>> file times are within the signed 32 bit time_t range).
>>
>> My understanding is mips is the only outlier here with unsigned
>> kernel stat times, which on glibc is handled with a special function
>> that just that interprets the values as 2106 timestamp
>> (__cp_kstat_stat64_t64).
>
> Ok, got it. In this case I guess we should probably follow the
> same behavior in the kernel when we add the truncation and
> use the 1902..2038 range for all 32-bit targets but use the
> 1970..2106 range for mips64. Not sure what to do about
> mips32 compat mode though. At the moment, the o32/n32 stat64
> is shared with the n64 stat ("newstat") variant, but if n64
> actually wants a different behavior, we may need to add custom
> handlers for that.
>
> Arnd
The mips64n32 uses the same code path as mips64, but mips32 assumes
the same ABI for old legacy 32 bit architectures (fstatat64 syscall
with signed time_t). So for compat mode mips32 is also handled as
unsigned? Is it only for compat mode, and not for 32-bit kernel?
next prev parent reply other threads:[~2022-11-08 12:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 1:54 YunQiang Su
2022-11-04 10:02 ` Arnd Bergmann
2022-11-07 18:08 ` Adhemerval Zanella Netto
2022-11-07 18:24 ` Arnd Bergmann
2022-11-07 18:45 ` Adhemerval Zanella Netto
2022-11-08 11:21 ` Arnd Bergmann
2022-11-08 12:04 ` Adhemerval Zanella Netto [this message]
2022-11-17 16:47 ` Adhemerval Zanella Netto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ccb6d5c-e054-29cd-06ce-04ef5ee312b8@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=arnd@arndb.de \
--cc=aurelien@aurel32.net \
--cc=jiaxun.yang@flygoat.com \
--cc=libc-alpha@sourceware.org \
--cc=macro@orcam.me.uk \
--cc=syq@debian.org \
--cc=yunqiang.su@cipunited.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).