Hi John,
On Wed, Aug 20, 2025 at 01:03:56AM -0700, John Stultz wrote:
On Tue, Jul 1, 2025 at 1:58 AM Thomas Weißschuh thomas.weissschuh@linutronix.de wrote:
Expose the auxiliary clocks through the vDSO.
Architectures not using the generic vDSO time framework, namely SPARC64, are not supported.
Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de
Just as a heads up, I've just been bisecting and this commit seems to be causing problems on arm64 devices, running 32bit versions of kselftest nanosleep or inconsistency-check tests. Running the 64bit versions of the tests are not showing issues.
Thanks for the report, I can reproduce the issue.
From my initial digging, it looks like clockids that aren't vdso enabled (CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID, CLOCK_REALTIME_ALARM, CLOCK_BOOTTIME_ALARM) are somehow getting caught in the vdso logic and are *not* falling back to the syscall (stracing the test I don't see syscalls happen before the failure), and the values returned don't look to be correct.
The generic vDSO code assumes that it can use the UAPI headers, also in the compat vDSO. This is true for most architectures, as the UAPI headers work correctly in 32-bit and 64-bit mode. On arm64 this is different, as the headers from arm64/ are never used by regular 32-bit userpspace. So arch/arm64/include/uapi/asm/bitsperlong.h defines __BITS_PER_LONG=64 even when used by the 32-bit compat vDSO. The commit you identified uses __GENMASK() which uses __BITS_PER_LONG. Due to the mismatch between __BITS_PER_LONG and the real long datatype we run into an out-of-bounds shift and therefore undefined behaviour. And of course -Wshift-count-overflow is explicitly disabled.
There are a few possible fixes, none of which is really great. I'll send some patches.
The inconsistency-check output looks like:
(...)
Which hints we're returning nanosecond values in the tv_sec field somehow.
That seems to be an artifact of the UB from above, this happens even if do_aux() just returns 'false'.
Thomas