On Fri, Nov 14, 2025, at 09:48, Thomas Weißschuh wrote:
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:
__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.
In what way? When we introduced the clock_gettime64() vdso call, we debated also adding time64(), gettimeofday_time64() and clock_getres_time64() but decided against that based on the argument that the libc can implement all of these efficiently with just clock_gettime64().
If you think that clock_getres_time64() is important, I don't mind changing that, especially now that we have a shared vdso for all architectures. The arguments here is a bit different, since an efficient clock_getres() function in libc requires caching the values in userspace, while an efficient gettimeofday() is much simpler, by calling vdso_clock_gettime_time64()
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.
Sorry, I'm not following. Do you mean we need the mangling since we support the vdso for configurations without the direct syscalls, or do you mean something else?
I don't think we can actually build a full userspace (other than nolibc) that works with CONFIG_COMPAT_32BIT_TIME=n, so I'm not particularly worried about testing the vdso for that case. You already skip testing vdso_time() if sys_time() is unavailable, and I think we can do it the exact same way for all five vdso calls.
sys_clock_gettime() should probably be called sys_clock_gettime64(), as that is what it actually is.
That also seems wrong, as there is no clock_gettime64 on 64-bit architectures, only clock_gettime.
FYI: gettimeoday() seems to be available even in kernels without CONFIG_COMPAT_32BIT_TIME.
I see, that does sound like a mistake. It's relatively harmless, but I think it would be safe to change this along with changing the vdso to only expose the time32 interfaces when COMPAT_32BIT_TIME is enabled.
Arnd