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 ]
Showing the changes to kernel (1 of 1 file). Show all
Unified · Split
| @@ -93,7 +93,17 @@ void tick_handle_periodic(struct clock_event_device *dev) · 92 unmodified lines | |||
| 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 | } |