clockevents: prevent endless loop in tick_handle_periodic()
tick_handle_periodic() can lock up hard when a one shot clock event device is used in combination with jiffies clocksource. Avoid an endless loop issue by requiring that a highres valid clocksource be installed before we call tick_periodic() in a loop when using ONESHOT mode. The result is we will only increment jiffies once per interrupt until a continuous hardware clocksource is available. Without this, we can run into a endless loop, where each cycle through the loop, jiffies is updated which increments time by tick_period or more (due to clock steering), which can cause the event programming to think the next event was before the newly incremented time and fail causing tick_periodic() to be called again and the whole process loops forever. [ Impact: prevent hard lock up ] Signed-off-by: John Stultz <johnstul@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org
This commit is contained in:
parent
091438dd56
commit
74a03b69d1
1 changed files with 11 additions and 1 deletions
|
@ -93,7 +93,17 @@ void tick_handle_periodic(struct clock_event_device *dev)
|
|||
for (;;) {
|
||||
if (!clockevents_program_event(dev, next, ktime_get()))
|
||||
return;
|
||||
tick_periodic(cpu);
|
||||
/*
|
||||
* Have to be careful here. If we're in oneshot mode,
|
||||
* before we call tick_periodic() in a loop, we need
|
||||
* to be sure we're using a real hardware clocksource.
|
||||
* Otherwise we could get trapped in an infinite
|
||||
* loop, as the tick_periodic() increments jiffies,
|
||||
* when then will increment time, posibly causing
|
||||
* the loop to trigger again and again.
|
||||
*/
|
||||
if (timekeeping_valid_for_hres())
|
||||
tick_periodic(cpu);
|
||||
next = ktime_add(next, tick_period);
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Reference in a new issue