diff options
author | john stultz <johnstul@us.ibm.com> | 2009-05-01 16:10:25 -0400 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2009-05-02 04:22:27 -0400 |
commit | 74a03b69d1b5ce00a568e142ca97e76b7f5239c6 (patch) | |
tree | 02bdea43ae6d528dcee97c00c3a8651f8841411a | |
parent | 091438dd5668396328a3419abcbc6591159eb8d1 (diff) |
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
-rw-r--r-- | kernel/time/tick-common.c | 12 |
1 files changed, 11 insertions, 1 deletions
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 21a5ca849514..83c4417b6a3c 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c | |||
@@ -93,7 +93,17 @@ void tick_handle_periodic(struct clock_event_device *dev) | |||
93 | for (;;) { | 93 | for (;;) { |
94 | if (!clockevents_program_event(dev, next, ktime_get())) | 94 | if (!clockevents_program_event(dev, next, ktime_get())) |
95 | return; | 95 | return; |
96 | tick_periodic(cpu); | 96 | /* |
97 | * Have to be careful here. If we're in oneshot mode, | ||
98 | * before we call tick_periodic() in a loop, we need | ||
99 | * to be sure we're using a real hardware clocksource. | ||
100 | * Otherwise we could get trapped in an infinite | ||
101 | * loop, as the tick_periodic() increments jiffies, | ||
102 | * when then will increment time, posibly causing | ||
103 | * the loop to trigger again and again. | ||
104 | */ | ||
105 | if (timekeeping_valid_for_hres()) | ||
106 | tick_periodic(cpu); | ||
97 | next = ktime_add(next, tick_period); | 107 | next = ktime_add(next, tick_period); |
98 | } | 108 | } |
99 | } | 109 | } |