On Tue, Nov 11, 2025, at 14:55, Thomas Weißschuh wrote:
On Tue, Nov 11, 2025 at 01:59:02PM +0100, Arnd Bergmann wrote:
On Tue, Nov 11, 2025, at 11:49, Thomas Weißschuh wrote:
+#ifdef SYS_clock_getres ret = syscall(SYS_clock_getres, clk_id, &sys_ts); +#else
- ret = syscall(SYS_clock_getres_time32, clk_id, &sys_ts);
+#endif
I think this #ifdef check is not reliable enough and may hide bugs. As with the other syscalls, the best way to call these is to either use __NR_clock_getres_time64 on __kernel_timespec, or to use __NR_clock_getres on __kernel_old_timespec.
Could you give an example for such a bug?
If CONFIG_COMPAT_32BIT_TIME is disabled, 32-bit targets only provide clock_getres_time64, so using SYS_clock_getres may -ENOSYS.
Since SYS_clock_getres itself is provided by the libc implementation, I wouldn't trust that this actually means the same as __NR_clock_getres, and it might be set to __NR_clock_getres_time64.
If we are trying to validate the interface here, we should probably call both if available. If we just want to know the result and trust that both work correctly, I'd always use __NR_clock_getres_time64 on 32-bit systems and __NR_clock_getres on 64-bit systems.
As these are vDSO and not timer selftests I think we trust the syscalls. But how do we detect a native 64-bit time system? The preprocessor builtins won't work as a 32-bit pointer system may use 64-bit time syscalls. I am not aware of the UAPI #define, beyond the absence of __NR_clock_getres_time64.
I would just check __BITS_PER_LONG=32 and require a linux-5.6+ kernel at runtime to ensure the 64-bit calls are available.
Arnd