[Bug libc/29730] broken y2038 support in fstatat on MIPS N64

["aurelien at aurel32 dot net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29730

--- Comment #23 from Aurelien Jarno <aurelien at aurel32 dot net> ---
(In reply to Aurelien Jarno from comment #22)
> (In reply to YunQiang Su from comment #19)
> > (In reply to Adhemerval Zanella from comment #17)
> > > (In reply to YunQiang Su from comment #14)
> > > > Created attachment 14422 [details]
> > > > define in_int32_t_range
> > > 
> > > Besides the stat issue (which I just send a fix for it [1]), is there
> > > another case where in_time_t_range is being used by an ABI with 64-bit time
> > > that will trigger and invalid usage?
> > > 
> > > I am kind worried to change such code again, since it will require even more
> > > validation that this does not subtle break anymore more.
> > > 
> > > [1] https://sourceware.org/pipermail/libc-alpha/2022-October/143089.html
> > 
> > Always Keep the function name sync with what it is doing.
> > 
> > We should use in_int32_t_range to determin the 32bit syscall or 64bit one
> > to use, in the bellow files:
> >           sysdeps/unix/sysv/linux/clock_adjtime.c
> >           sysdeps/unix/sysv/linux/timer_settime.c:
> >           sysdeps/unix/sysv/linux/clock_nanosleep.c
> >           sysdeps/unix/sysv/linux/clock_settime.c
> >           sysdeps/unix/sysv/linux/pselect.c
> >           sysdeps/unix/sysv/linux/mq_timedreceive.c
> >           sysdeps/unix/sysv/linux/semtimedop.c
> >           sysdeps/unix/sysv/linux/mq_timedsend.c
> >           sysdeps/unix/sysv/linux/ppoll.c
> >           sysdeps/unix/sysv/linux/setitimer.c
> >           sysdeps/unix/sysv/linux/utimensat.c
> >           sysdeps/unix/sysv/linux/recvmmsg.c
> >           sysdeps/unix/sysv/linux/timerfd_settime.c
> >           sysdeps/unix/sysv/linux/setsockopt.c
> >           sysdeps/unix/sysv/linux/sigtimedwait.c
> >           sysdeps/unix/sysv/linux/select.c
> >           nptl/futex-internal.c
> > 
> > We should use in_time_t_range to detect overflow from the syscall retval:
> >           time/timegm.c
> >           time/mktime.c
> 
> For these above two your choice is correct, but it's not linked to syscall
> retval.
> 
> >           sysdeps/unix/sysv/linux/ftime.c
> >           sysdeps/unix/sysv/linux/sched_rr_gi.c
> >           sysdeps/unix/sysv/linux/stat_t64_cp.c
> >           sysdeps/unix/sysv/linux/time.c
> >           sysdeps/unix/sysv/linux/timespec_get.c
> >           sysdeps/unix/sysv/linux/gettimeofday.c
> >           sysdeps/unix/sysv/linux/clock_gettime.c
> >           sysdeps/unix/sysv/linux/fstatat.c
> 
> Additional comments:
> - No need to change int32_t into __int32_t in __timeval32
> - Renaming STAT_HAS_TIME32 into KERNEL_STAT64_HAS_TIME32 is correct, but is
> not needed to fix the issue. I think it might go into a separate patch

Maybe you can post an updated patch to the mailing list for easier discussion?

-- 
You are receiving this mail because:
You are on the CC list for the bug.