On Tue, Nov 11, 2025 at 03:19:00PM +0100, Arnd Bergmann wrote: > 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.
Ok. That I am aware of. I expected something more subtle. > 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. Should that case not work anyways, as libc would also need to convert the parameters transparently? But I'll switch it over to __NR instead. > >> 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. That doesn't work for x32. It uses __BITS_PER_LONG but does not have __NR_clock_getres_time64. Thomas
