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:

quoted

On Tue, Jun 30, 2026, at 09:38, Thomas Weißschuh wrote:

quoted

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

quoted

quoted

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.

quoted

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 <arnd@arndb.de>