diff options
author | John Stultz <john.stultz@linaro.org> | 2012-03-15 13:04:03 -0700 |
---|---|---|
committer | John Stultz <john.stultz@linaro.org> | 2012-03-22 19:43:43 -0700 |
commit | 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d (patch) | |
tree | 007df06a9cf0d4d2b72ed7dd8d646e853de80e9b /kernel/groups.c | |
parent | 57779dc2b3b75bee05ef5d1ada47f615f7a13932 (diff) | |
download | op-kernel-dev-6b43ae8a619d17c4935c3320d2ef9e92bdeed05d.zip op-kernel-dev-6b43ae8a619d17c4935c3320d2ef9e92bdeed05d.tar.gz |
ntp: Fix leap-second hrtimer livelock
Since commit 7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 the ntp
subsystem has used an hrtimer for triggering the leapsecond
adjustment. However, this can cause a potential livelock.
Thomas diagnosed this as the following pattern:
CPU 0 CPU 1
do_adjtimex()
spin_lock_irq(&ntp_lock);
process_adjtimex_modes(); timer_interrupt()
process_adj_status(); do_timer()
ntp_start_leap_timer(); write_lock(&xtime_lock);
hrtimer_start(); update_wall_time();
hrtimer_reprogram(); ntp_tick_length()
tick_program_event() spin_lock(&ntp_lock);
clockevents_program_event()
ktime_get()
seq = req_seqbegin(xtime_lock);
This patch tries to avoid the problem by reverting back to not using
an hrtimer to inject leapseconds, and instead we handle the leapsecond
processing in the second_overflow() function.
The downside to this change is that on systems that support highres
timers, the leap second processing will occur on a HZ tick boundary,
(ie: ~1-10ms, depending on HZ) after the leap second instead of
possibly sooner (~34us in my tests w/ x86_64 lapic).
This patch applies on top of tip/timers/core.
CC: Sasha Levin <levinsasha928@gmail.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Diagnoised-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Diffstat (limited to 'kernel/groups.c')
0 files changed, 0 insertions, 0 deletions