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

[Thomas Weißschuh]

On Wed, Mar 04, 2026 at 10:30:34AM -0800, H. Peter Anvin wrote:
> On March 3, 2026 11:35:52 PM PST, "Thomas Weißschuh" <thomas.weissschuh at linutronix.de> wrote:
> >On Tue, Mar 03, 2026 at 10:11:52AM -0800, 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.
> >
> >sys_tz is currently used by a bunch of drivers and filesystems (including FAT).
> >It is also used when writing to the RTC.
> >
> >> 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 am a bit confused here. You mention 'link failures' and in another mail
> >'weak references as fallback'. Both are things that happen during linking
> >('link failures' could also be interpreted as failures during loading).
> >Somewhere else someone also mentioned the vDSO to be 'linkable'.
> >But as far as I understand, only libc interprets the vDSO, it completely
> >bypasses both the linker and the loader. And libc already does graceful
> >fallbacks to the regular systemcalls if the vDSO is missing completely or
> >lacks one of the functions, as both cases may happen on normal systems.
> >
> >What am I missing?

> Weak references would be a way to work around the link failures. 

I am still not sure where "the link failures" should be coming from.
The only sense I can make out of it, is if somebody manually and directly links
to vdso.so. Like in the following example:

$ cat test.c 
#include <stdio.h>

#include <linux/time.h>

int __vdso_clock_gettime(__kernel_clockid_t clock, struct __kernel_timespec *ts);

int main(void)
{
	struct __kernel_timespec ts;
	int ret;

	printf("__vdso_clock_gettime=%p\n", __vdso_clock_gettime);

	ret = __vdso_clock_gettime(CLOCK_REALTIME, &ts);
	printf("ret=%d\n", ret);
}
$ gcc test.c /lib/modules/$(uname -r)/vdso/vdso64.so
$ ./a.out 
__vdso_clock_gettime=0x7ff6ba2eeb80
ret=0

This actually works on glibc (not on musl). But it is highly non-standard and
relies on multiple implementation details. Furthermore it can fail to run on
systems without a vDSO, as mentioned before.

Is this the usage pattern you have in mind?
Do you know of anybody doing things this way?


(...)


Thomas