On Wed, Jul 1, 2026, at 10:40, Thomas Weißschuh wrote: > On Tue, Jun 30, 2026 at 03:00:37PM +0200, Arnd Bergmann wrote: >> On Tue, Jun 30, 2026, at 09:38, Thomas Weißschuh wrote: >> > The "old" time types use 32-bit seconds which are not y2038-safe. >> > Respect COMPAT_32BIT_TIME for functions using those types. >> > time(), stime() and gettimeofday() are disabled completely. >> >> Looks good, yes > > Sashiko found an issue [0], which I think is valid. I'll change that for v3.
Ok >> > settimeofday() is kept as it is required to do the initial timewarping >> > after boot. However the 'tv' argument will be rejected. >> >> Not sure about this part, did we already discuss this last time? > > This is my interpretation of [1]. Indeed, we did. >> I can see how keeping the timewarping functionality is the easy way >> out, but completely disabling the settimeofday syscall the same >> way we do on new architectures seems so much more consistent. > > Shouldn't we then do this completely? Irrespective of COMPAT_32BIT_TIME? > And then remove all of the timewarping and kernel timezone bits. I don't think we can simply kill the timewarping code since that likely has users on architectures including on x86-64. COMPAT_32BIT_TIME=n is somewhat special because this is an intentional (and optional) ABI break already and requires updated userspace that avoids the time32 syscalls. Having the timewarp still in settimeofday() or dropping it entirely is not that different for userspace. I was slightly worried about whether returning -EINVAL or -ENOSYS is the better option here, but I think your choice is the correct one after seeing that this is what glibc does other invalid cases, and that in all of codesearch.debian.net, I could not find a single caller that would care about the difference. > It would be nice however if this series, and my other ones blocked behind it, > are not blocked on that larger rework. Sure. I think you can go ahead with this version. I would prefer to not have any settimeofday() for the COMPAT_32BIT_TIME=n case, but if nobody else has a strong opinion on the matter, let's do it your way. Reviewed-by: Arnd Bergmann <[email protected]>
