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
 
 	ksft_print_msg("The syscall resolution is %lld %lld\n",
 			(long long)sys_ts.tv_sec, (long long)sys_ts.tv_nsec);

-- 
2.51.0

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.

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.

      Arnd

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