Merge tag 'timers-urgent-2025-04-06' of git://git.kernel.org/pub/scm/linux/kernel...
authorLinus Torvalds <torvalds@linux-foundation.org>
Sun, 6 Apr 2025 15:13:16 +0000 (08:13 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Sun, 6 Apr 2025 15:13:16 +0000 (08:13 -0700)
commita91c49517de3445bc438d29a5bb481338817791e
tree48c6a00366dbd601a7fb13530099699e47abc967
parent1f80fbac0ba7d10218b0902c3c51460617cc7cf8
parent324a2219ba38b00ab0e53bd535782771ba9614b2
Merge tag 'timers-urgent-2025-04-06' of git://git./linux/kernel/git/tip/tip

Pull timer fix from Thomas Gleixner:
 "A revert to fix a adjtimex() regression:

  The recent change to prevent that time goes backwards for the coarse
  time getters due to immediate multiplier adjustments via adjtimex(),
  changed the way how the timekeeping core treats that.

  That change result in a regression on the adjtimex() side, which is
  user space visible:

   1) The forwarding of the base time moves the update out of the
      original period and establishes a new one. That's changing the
      behaviour of the [PF]LL control, which user space expects to be
      applied periodically.

   2) The clearing of the accumulated NTP error due to #1, changes the
      behaviour as well.

  An attempt to delay the multiplier/frequency update to the next tick
  did not solve the problem as userspace expects that the multiplier or
  frequency updates are in effect, when the syscall returns.

  There is a different solution for the coarse time problem available,
  so revert the offending commit to restore the existing adjtimex()
  behaviour"

* tag 'timers-urgent-2025-04-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  Revert "timekeeping: Fix possible inconsistencies in _COARSE clockids"