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 <[email protected]> > > --- > > 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
