* [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 @ 2022-11-04 1:54 YunQiang Su 2022-11-04 10:02 ` Arnd Bergmann 2022-11-17 16:47 ` Adhemerval Zanella Netto 0 siblings, 2 replies; 8+ messages in thread From: YunQiang Su @ 2022-11-04 1:54 UTC (permalink / raw) To: libc-alpha Cc: aurelien, adhemerval.zanella, jiaxun.yang, macro, syq, YunQiang Su 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. --- sysdeps/unix/sysv/linux/fstatat64.c | 2 +- sysdeps/unix/sysv/linux/mips/kernel_stat.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sysdeps/unix/sysv/linux/fstatat64.c b/sysdeps/unix/sysv/linux/fstatat64.c index 8b1a1a290d..532b9beb67 100644 --- a/sysdeps/unix/sysv/linux/fstatat64.c +++ b/sysdeps/unix/sysv/linux/fstatat64.c @@ -42,7 +42,7 @@ _Static_assert (sizeof (__blkcnt_t) == sizeof (__blkcnt64_t), #if (__WORDSIZE == 32 \ && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE == 32)) \ - || defined STAT_HAS_TIME32 \ + || defined KERNEL_STAT64_HAS_TIME32 \ || (!defined __NR_newfstatat && !defined __NR_fstatat64) # define FSTATAT_USE_STATX 1 diff --git a/sysdeps/unix/sysv/linux/mips/kernel_stat.h b/sysdeps/unix/sysv/linux/mips/kernel_stat.h index 19524f7ea4..044adfb8df 100644 --- a/sysdeps/unix/sysv/linux/mips/kernel_stat.h +++ b/sysdeps/unix/sysv/linux/mips/kernel_stat.h @@ -69,7 +69,7 @@ struct kernel_stat #endif /* MIPS64 has unsigned 32 bit timestamps fields, so use statx as well. */ #if _MIPS_SIM == _ABI64 -# define STAT_HAS_TIME32 +# define KERNEL_STAT64_HAS_TIME32 #endif #endif -- 2.30.2 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 2022-11-04 1:54 [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 YunQiang Su @ 2022-11-04 10:02 ` Arnd Bergmann 2022-11-07 18:08 ` Adhemerval Zanella Netto 2022-11-17 16:47 ` Adhemerval Zanella Netto 1 sibling, 1 reply; 8+ messages in thread From: Arnd Bergmann @ 2022-11-04 10:02 UTC (permalink / raw) To: YunQiang Su, Xi Ruoyao; +Cc: syq, Jiaxun Yang, aurelien, Maciej W. Rozycki 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 2022-11-04 10:02 ` Arnd Bergmann @ 2022-11-07 18:08 ` Adhemerval Zanella Netto 2022-11-07 18:24 ` Arnd Bergmann 0 siblings, 1 reply; 8+ messages in thread From: Adhemerval Zanella Netto @ 2022-11-07 18:08 UTC (permalink / raw) To: Arnd Bergmann, YunQiang Su, Xi Ruoyao Cc: syq, aurelien, Jiaxun Yang, Maciej W. Rozycki 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 2022-11-07 18:08 ` Adhemerval Zanella Netto @ 2022-11-07 18:24 ` Arnd Bergmann 2022-11-07 18:45 ` Adhemerval Zanella Netto 0 siblings, 1 reply; 8+ messages in thread From: Arnd Bergmann @ 2022-11-07 18:24 UTC (permalink / raw) To: Adhemerval Zanella Netto, YunQiang Su, Xi Ruoyao Cc: syq, aurelien, Jiaxun Yang, Maciej W. Rozycki On Mon, Nov 7, 2022, at 19:08, Adhemerval Zanella Netto wrote: > On 04/11/22 07:02, Arnd Bergmann wrote: > 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. I think we need to coordinate this when we change the kernel to add truncation of the 64-bit time values. It sounds like glibc does an 'unsigned int' to 'long long' conversion for the legacy stat syscall, rather than a conversion from a signed value, and it would be helpful to have a matching interpretation between kernel and glibc. 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? Arnd ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 2022-11-07 18:24 ` Arnd Bergmann @ 2022-11-07 18:45 ` Adhemerval Zanella Netto 2022-11-08 11:21 ` Arnd Bergmann 0 siblings, 1 reply; 8+ messages in thread From: Adhemerval Zanella Netto @ 2022-11-07 18:45 UTC (permalink / raw) To: Arnd Bergmann, YunQiang Su, Xi Ruoyao Cc: syq, aurelien, Jiaxun Yang, Maciej W. Rozycki On 07/11/22 15:24, Arnd Bergmann wrote: > On Mon, Nov 7, 2022, at 19:08, Adhemerval Zanella Netto wrote: >> On 04/11/22 07:02, Arnd Bergmann wrote: > >> 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. > > I think we need to coordinate this when we change the kernel to > add truncation of the 64-bit time values. It sounds like glibc > does an 'unsigned int' to 'long long' conversion for the legacy > stat syscall, rather than a conversion from a signed value, and > it would be helpful to have a matching interpretation between > kernel and glibc. > > 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? > > Arnd 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). ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 2022-11-07 18:45 ` Adhemerval Zanella Netto @ 2022-11-08 11:21 ` Arnd Bergmann 2022-11-08 12:04 ` Adhemerval Zanella Netto 0 siblings, 1 reply; 8+ messages in thread From: Arnd Bergmann @ 2022-11-08 11:21 UTC (permalink / raw) To: Adhemerval Zanella Netto, YunQiang Su, Xi Ruoyao Cc: syq, aurelien, Jiaxun Yang, Maciej W. Rozycki 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 2022-11-08 11:21 ` Arnd Bergmann @ 2022-11-08 12:04 ` Adhemerval Zanella Netto 0 siblings, 0 replies; 8+ messages in thread From: Adhemerval Zanella Netto @ 2022-11-08 12:04 UTC (permalink / raw) To: Arnd Bergmann, YunQiang Su, Xi Ruoyao Cc: syq, aurelien, Jiaxun Yang, Maciej W. Rozycki 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 2022-11-04 1:54 [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 YunQiang Su 2022-11-04 10:02 ` Arnd Bergmann @ 2022-11-17 16:47 ` Adhemerval Zanella Netto 1 sibling, 0 replies; 8+ messages in thread From: Adhemerval Zanella Netto @ 2022-11-17 16:47 UTC (permalink / raw) To: YunQiang Su, libc-alpha; +Cc: aurelien, jiaxun.yang, macro, syq On 03/11/22 22: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 am not seeing much gain in this refactor, it is only an internal define used once and on its definition it already states the problem (and the y2106 issue is already stated in 5b980d48099130). I prefer to keep current macro so keep git history simpler. > --- > sysdeps/unix/sysv/linux/fstatat64.c | 2 +- > sysdeps/unix/sysv/linux/mips/kernel_stat.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sysdeps/unix/sysv/linux/fstatat64.c b/sysdeps/unix/sysv/linux/fstatat64.c > index 8b1a1a290d..532b9beb67 100644 > --- a/sysdeps/unix/sysv/linux/fstatat64.c > +++ b/sysdeps/unix/sysv/linux/fstatat64.c > @@ -42,7 +42,7 @@ _Static_assert (sizeof (__blkcnt_t) == sizeof (__blkcnt64_t), > > #if (__WORDSIZE == 32 \ > && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE == 32)) \ > - || defined STAT_HAS_TIME32 \ > + || defined KERNEL_STAT64_HAS_TIME32 \ > || (!defined __NR_newfstatat && !defined __NR_fstatat64) > # define FSTATAT_USE_STATX 1 > > diff --git a/sysdeps/unix/sysv/linux/mips/kernel_stat.h b/sysdeps/unix/sysv/linux/mips/kernel_stat.h > index 19524f7ea4..044adfb8df 100644 > --- a/sysdeps/unix/sysv/linux/mips/kernel_stat.h > +++ b/sysdeps/unix/sysv/linux/mips/kernel_stat.h > @@ -69,7 +69,7 @@ struct kernel_stat > #endif > /* MIPS64 has unsigned 32 bit timestamps fields, so use statx as well. */ > #if _MIPS_SIM == _ABI64 > -# define STAT_HAS_TIME32 > +# define KERNEL_STAT64_HAS_TIME32 > #endif > > #endif ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-11-17 16:47 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-04 1:54 [PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32 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 2022-11-17 16:47 ` Adhemerval Zanella Netto
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).