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:
The 32-bit time variants on musl have different names, provide a fallback.
Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de
tools/testing/selftests/vDSO/vdso_test_abi.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/vDSO/vdso_test_abi.c b/tools/testing/selftests/vDSO/vdso_test_abi.c index bb5a5534ae7e8a46d7e68a561684c29a752b866d..0a6b16a21369642384d43b0efd1bca227a2a4298 100644 --- a/tools/testing/selftests/vDSO/vdso_test_abi.c +++ b/tools/testing/selftests/vDSO/vdso_test_abi.c @@ -166,7 +166,11 @@ static void vdso_test_clock_getres(__kernel_clockid_t clk_id) clock_getres_fail++; }
+#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 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.
Thomas