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 ]

john stultz committed 17 years ago

Commit 74a03b61 parent 091438d1 file · +11 −1Browse files

Showing the changes to kernel (1 of 1 file). Show all

Unified · Split

kernel/time/tick-common.c+11−1

@@ -93,7 +93,17 @@ void tick_handle_periodic(struct clock_event_device *dev) · 92 unmodified lines
93	93	for (;;) {
94	94	if (!clockevents_program_event(dev, next, ktime_get()))
95	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	107	next = ktime_add(next, tick_period);
98	108	}
99	109	}