Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

["H. Peter Anvin" <hpa@zytor.com>]

On March 3, 2026 12:50:33 PM PST, Arnd Bergmann <arnd@arndb.de> wrote:
>On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote:
>> On 2026-02-27 01:34, Thomas Weißschuh wrote:
>>>>>
>>>> The thing about gettimeofday() and time() is that they don't have
>>>> a 64-bit version and libc implementations are expected to call
>>>> clock_gettime() instead. The result was that there was never a
>>>> patch to turn the off either.
>>> 
>>> gettimeofday() is currently the only way to get the timezone of the kernel.
>>> But I guess this is a legacy thing anyways. If you say we should drop it,
>>> let's drop it.
>>> 
>>
>> The time zone in the kernel has never worked anyway, as it would require the
>> kernel to contain at least the forward portion of the zoneinfo/tzdata table in
>> order to actually work correctly. The only plausible use of it would be for
>> local time-based filesystems like FAT, but I don't think we bother.
>>
>> A bigger question is whether or not we should omit these from the vDSO
>> completely (potentially causing link failures) or replace them with stubs
>> returning -ENOSYS.
>
>I see no harm in keeping gettimeofday() in the vdso when
>COMPAT_32BIT_TIME is turned on, as existing code will call it
>no matter whether it's in the vdso or the syscall.
>
>Equally, I see no point in having either version of
>gettimeofday() or settimeofday() when COMPAT_32BIT_TIME is
>disabled, as clearly anything calling it would pass incorrect
>data for times past 2038.
>
>Neither glibc nor musl support actually returning the kernel
>timezone to callers of gettimeofday in modern versions that
>support time64 syscalls.
>
>      Arnd
>

That wasn't the point. The point was what kind of error behavior we want.