Re: [PATCH] linux: Fix fstatat with !XSTAT_IS_XSTAT64 and __TIMESIZE=64 (BZ #29730)

[Aurelien Jarno <aurelien@aurel32.net>]

On 2022-10-31 14:25, Adhemerval Zanella Netto via Libc-alpha wrote:
> 
> 
> On 31/10/22 13:03, Adhemerval Zanella Netto wrote:
> > 
> > 
> > On 28/10/22 17:54, Aurelien Jarno wrote:
> >> Commit 6e8a0aac2f883 ("time: Fix overflow itimer tests on 32-bit
> >> systems") changed in_time_t_range to assume a 32-bit time_t. Therefore
> >> stop calling it from __fstatat for systems with 64-bit time_t.
> >>
> >> Resolves: BZ #29730
> > 
> > Although this change is not incorrect, I think the fix I just sent [1] is 
> > slight better because it just alias non-LFS stat to LFS stat for mips 
> > (which is also a small runtime and code optimization), while avoiding 
> > touching generic code (so we need to check if trigger another issue on 
> > different architecture).
> > 
> > [1] https://sourceware.org/pipermail/libc-alpha/2022-October/143089.html
> 
> So I was wrong that we can assume stat and stat64 are equal on mips.  Maybe
> instead of adding the fix on stat we can make it more generic and move it
> to is_time_t_range (so it can potentially fix usage not only on stat code)
> as my comment on https://sourceware.org/bugzilla/show_bug.cgi?id=29730 ?

Yes, we can move it to is_time_t_range, but then it gets trickier to get
the condition. Your comment in BZ #29730 uses TIME64_NON_DEFAULT, but it
is not defined for OpenRISC, so it means it will cast to time_t. However
this has been explicitly changed that way in commit 6e8a0aac2f883 to
unbreak OpenRISC.

We probably want a condition that is "kernel ABI uses 32-bit time_t". Do
we have something like that already defined?

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net