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
