On Tue, Jul 1, 2025 at 1:58 AM Thomas Weißschuh <thomas.weisssc...@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.weisssc...@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. >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 inconsistency-check output looks like: # 5983032:0 # 5983317:0 # 5983561:0 # 5983846:0 # 5984130:0 # 5984415:0 # -------------------- # 5984659:0 # 2009440:0 # -------------------- # 2009724:0 # 2009969:0 # 2010253:0 # 2010538:0 # 2010782:0 # 2011067:0 Which hints we're returning nanosecond values in the tv_sec field somehow. Reverting just this change gets things back to working. It's pretty late here, so I'm going to try to dig a bit further to understand what's going on tomorrow, but wanted to raise this in case it's more obvious to less tired eyes. :) thanks -john
