Thomas Gleixner b71f9804f6 timekeeping: Prevent coarse clocks going backwards ... Lei Chen raised an issue with CLOCK_MONOTONIC_COARSE seeing time inconsistencies. Lei tracked down that this was being caused by the adjustment: tk->tkr_mono.xtime_nsec -= offset; which is made to compensate for the unaccumulated cycles in offset when the multiplicator is adjusted forward, so that the non-_COARSE clockids don't see inconsistencies. However, the _COARSE clockid getter functions use the adjusted xtime_nsec value directly and do not compensate the negative offset via the clocksource delta multiplied with the new multiplicator. In that case the caller can observe time going backwards in consecutive calls. By design, this negative adjustment should be fine, because the logic run from timekeeping_adjust() is done after it accumulated approximately multiplicator * interval_cycles into xtime_nsec. The accumulated value is always larger then the mult_adj * offset value, which is subtracted from xtime_nsec. Both operations are done together under the tk_core.lock, so the net change to xtime_nsec is always always be positive. However, do_adjtimex() calls into timekeeping_advance() as well, to apply the NTP frequency adjustment immediately. In this case, timekeeping_advance() does not return early when the offset is smaller then interval_cycles. In that case there is no time accumulated into xtime_nsec. But the subsequent call into timekeeping_adjust(), which modifies the multiplicator, subtracts from xtime_nsec to correct for the new multiplicator. Here because there was no accumulation, xtime_nsec becomes smaller than before, which opens a window up to the next accumulation, where the _COARSE clockid getters, which don't compensate for the offset, can observe the inconsistency. This has been tried to be fixed by forwarding the timekeeper in the case that adjtimex() adjusts the multiplier, which resets the offset to zero: 757b000f7b ("timekeeping: Fix possible inconsistencies in _COARSE clockids") That works correctly, but unfortunately causes a regression on the adjtimex() side. There are two issues: 1) The forwarding of the base time moves the update out of the original period and establishes a new one. 2) The clearing of the accumulated NTP error is changing the behaviour as well. User-space expects that multiplier/frequency updates are in effect, when the syscall returns, so delaying the update to the next tick is not solving the problem either. Commit 757b000f7b was reverted so that the established expectations of user space implementations (ntpd, chronyd) are restored, but that obviously brought the inconsistencies back. One of the initial approaches to fix this was to establish a separate storage for the coarse time getter nanoseconds part by calculating it from the offset. That was dropped on the floor because not having yet another state to maintain was simpler. But given the result of the above exercise, this solution turns out to be the right one. Bring it back in a slightly modified form. Thus introduce timekeeper::coarse_nsec and store that nanoseconds part in it, switch the time getter functions and the VDSO update to use that value. coarse_nsec is set on operations which forward or initialize the timekeeper and after time was accumulated during a tick. If there is no accumulation the timestamp is unchanged. This leaves the adjtimex() behaviour unmodified and prevents coarse time from going backwards. [ jstultz: Simplified the coarse_nsec calculation and kept behavior so coarse clockids aren't adjusted on each inter-tick adjtimex call, slightly reworked the comments and commit message ] Fixes: da15cfdae0 ("time: Introduce CLOCK_REALTIME_COARSE") Reported-by: Lei Chen <lei.chen@smartx.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: John Stultz <jstultz@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/all/20250419054706.2319105-1-jstultz@google.com Closes: https://lore.kernel.org/lkml/20250310030004.3705801-1-lei.chen@smartx.com/		2025-04-28 11:17:29 +02:00
..
alarmtimer.c
clockevents.c
clocksource-wdtest.c
clocksource.c	treewide: Switch/rename to timer_delete[_sync]()	2025-04-05 10:30:12 +02:00
hrtimer.c	hrtimer: Add missing ACCESS_PRIVATE() for hrtimer::function	2025-04-09 21:00:42 +02:00
itimer.c
jiffies.c
Kconfig
Makefile	tracing: Disable branch profiling in noinstr code	2025-03-22 09:49:26 +01:00
namespace.c
ntp_internal.h
ntp.c
posix-clock.c	Networking changes for 6.15.	2025-03-26 21:48:21 -07:00
posix-cpu-timers.c
posix-stubs.c
posix-timers.c	A treewide hrtimer timer cleanup	2025-03-25 10:54:15 -07:00
posix-timers.h
sched_clock.c
sleep_timeout.c	treewide: Switch/rename to timer_delete[_sync]()	2025-04-05 10:30:12 +02:00
test_udelay.c
tick-broadcast-hrtimer.c
tick-broadcast.c
tick-common.c	timekeeping: Add a lockdep override in tick_freeze()	2025-04-09 22:30:39 +02:00
tick-internal.h
tick-legacy.c
tick-oneshot.c
tick-sched.c
tick-sched.h
time_test.c
time.c
timeconst.bc
timeconv.c
timecounter.c
timekeeping_debug.c
timekeeping_internal.h
timekeeping.c	timekeeping: Prevent coarse clocks going backwards	2025-04-28 11:17:29 +02:00
timekeeping.h
timer_list.c	hrtimers: Make callback function pointer private	2025-04-05 10:30:17 +02:00
timer_migration.c
timer_migration.h
timer.c	treewide: Switch/rename to timer_delete[_sync]()	2025-04-05 10:30:12 +02:00
vsyscall.c	timekeeping: Prevent coarse clocks going backwards	2025-04-28 11:17:29 +02:00