On Fri, Nov 14, 2025 at 09:13:02AM +0100, Arnd Bergmann wrote:
On Thu, Nov 13, 2025, at 16:30, Thomas Weißschuh wrote:
The vDSO selftests use raw system call wrapper to validate the correctness of the vDSO implementation. The exactly available system calls differ between architectures and kernel configurations. Raw system calls should not use libc types as these are not necessarily compatible.
Introduce a helper header which uses the correct types and fallbacks.
After I looked at how these are used in patch 8, I think it's much easier to just always use the same types as the kernel interfaces here and skip the type mangling entirely:
Please see below.
+static inline +int sys_clock_getres(__kernel_clockid_t clock, struct __kernel_timespec *ts) +{ +#ifdef __NR_clock_getres_time64
- return syscall(__NR_clock_getres_time64, clock, ts);
+#else
- ASSERT_TIMESPEC_COMPATIBLE(typeof(*ts), struct __kernel_old_timespec);
- return syscall(__NR_clock_getres, clock, ts);
+#endif +}
__NR_clock_getres and vdso_clock_getres() both always return a __kernel_old_timespec, so I now think it's best to return that from sys_clock_getres() without the __NR_clock_getres_time64 alternative here and not worry about whether that is a 32-bit or 64-bit type,
I should have thought this through better in my comments to the previous version.
In kernels without CONFIG_COMPAT_32BIT_TIME, we currently leave out the clock_getres/clock_gettime/gettimeofday/time syscalls, but still provide the vdso interfaces. For consistency we should probably leave out both syscall and vdso in that configuration, and then we also don't need to compare the vdso_getres result against sys_getres_time64.
That sounds good. But today no vDSO provides clock_getres_time64, so removing clock_getres from the vDSO will affect users. So we will end up with some sort of inconsistency in any case. While I agree that it would be nice if the type mangling was unnecessary, I prefer to correctly test what we have today. If we decide to simplify the vDSO itself then we have working tests.
sys_clock_gettime() should probably be called sys_clock_gettime64(), as that is what it actually is.
FYI: gettimeoday() seems to be available even in kernels without CONFIG_COMPAT_32BIT_TIME.
Thomas