diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2025-04-06 08:13:16 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2025-04-06 08:13:16 -0700 |
commit | a91c49517de3445bc438d29a5bb481338817791e (patch) | |
tree | 48c6a00366dbd601a7fb13530099699e47abc967 /scripts/gdb/linux/proc.py | |
parent | 1f80fbac0ba7d10218b0902c3c51460617cc7cf8 (diff) | |
parent | 324a2219ba38b00ab0e53bd535782771ba9614b2 (diff) | |
download | linux-stable-a91c49517de3445bc438d29a5bb481338817791e.tar.gz linux-stable-a91c49517de3445bc438d29a5bb481338817791e.tar.bz2 linux-stable-a91c49517de3445bc438d29a5bb481338817791e.zip |
Merge tag 'timers-urgent-2025-04-06' of git://git.kernel.org/pub/scm/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"
Diffstat (limited to 'scripts/gdb/linux/proc.py')
0 files changed, 0 insertions, 0 deletions