From: "Arnd Bergmann" <arnd@arndb.de>
To: "YunQiang Su" <yunqiang.su@cipunited.com>,
"Xi Ruoyao" <libc-alpha@sourceware.org>
Cc: syq@debian.org, "Jiaxun Yang" <jiaxun.yang@flygoat.com>,
aurelien@aurel32.net, "Maciej W. Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32
Date: Fri, 04 Nov 2022 11:02:41 +0100 [thread overview]
Message-ID: <50e745fa-0508-43f1-bd0a-cfa789239f7e@app.fastmail.com> (raw)
In-Reply-To: <20221104015428.1545677-1-yunqiang.su@cipunited.com>
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
next prev parent reply other threads:[~2022-11-04 10:03 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 [this message]
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
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=50e745fa-0508-43f1-bd0a-cfa789239f7e@app.fastmail.com \
--to=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).