From: Greg Kroah-Hartman Date: Mon, 29 Jan 2018 14:31:33 +0000 (+0100) Subject: 3.18-stable patches X-Git-Tag: v4.4.114~2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0393ef9c695d9b43b3f05a41d8b967330899fd49;p=thirdparty%2Fkernel%2Fstable-queue.git 3.18-stable patches added patches: hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch --- diff --git a/queue-3.18/hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch b/queue-3.18/hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch new file mode 100644 index 00000000000..d383d355523 --- /dev/null +++ b/queue-3.18/hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch @@ -0,0 +1,66 @@ +From d5421ea43d30701e03cadc56a38854c36a8b4433 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Fri, 26 Jan 2018 14:54:32 +0100 +Subject: hrtimer: Reset hrtimer cpu base proper on CPU hotplug + +From: Thomas Gleixner + +commit d5421ea43d30701e03cadc56a38854c36a8b4433 upstream. + +The hrtimer interrupt code contains a hang detection and mitigation +mechanism, which prevents that a long delayed hrtimer interrupt causes a +continous retriggering of interrupts which prevent the system from making +progress. If a hang is detected then the timer hardware is programmed with +a certain delay into the future and a flag is set in the hrtimer cpu base +which prevents newly enqueued timers from reprogramming the timer hardware +prior to the chosen delay. The subsequent hrtimer interrupt after the delay +clears the flag and resumes normal operation. + +If such a hang happens in the last hrtimer interrupt before a CPU is +unplugged then the hang_detected flag is set and stays that way when the +CPU is plugged in again. At that point the timer hardware is not armed and +it cannot be armed because the hang_detected flag is still active, so +nothing clears that flag. As a consequence the CPU does not receive hrtimer +interrupts and no timers expire on that CPU which results in RCU stalls and +other malfunctions. + +Clear the flag along with some other less critical members of the hrtimer +cpu base to ensure starting from a clean state when a CPU is plugged in. + +Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the +root cause of that hard to reproduce heisenbug. Once understood it's +trivial and certainly justifies a brown paperbag. + +Fixes: 41d2e4949377 ("hrtimer: Tune hrtimer_interrupt hang logic") +Reported-by: Paul E. McKenney +Signed-off-by: Thomas Gleixner +Cc: Peter Zijlstra +Cc: Sebastian Sewior +Cc: Anna-Maria Gleixner +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801261447590.2067@nanos +[bigeasy: backport to v3.18, drop ->next_timer it was introduced later] +Signed-off-by: Sebastian Andrzej Siewior +Signed-off-by: Greg Kroah-Hartman +--- + kernel/time/hrtimer.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/kernel/time/hrtimer.c ++++ b/kernel/time/hrtimer.c +@@ -612,6 +612,7 @@ static int hrtimer_reprogram(struct hrti + static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base) + { + base->expires_next.tv64 = KTIME_MAX; ++ base->hang_detected = 0; + base->hres_active = 0; + } + +@@ -1632,6 +1633,7 @@ static void init_hrtimers_cpu(int cpu) + timerqueue_init_head(&cpu_base->clock_base[i].active); + } + ++ cpu_base->active_bases = 0; + cpu_base->cpu = cpu; + hrtimer_init_hres(cpu_base); + } diff --git a/queue-3.18/series b/queue-3.18/series index 09f54f2c771..3c63f07cf4b 100644 --- a/queue-3.18/series +++ b/queue-3.18/series @@ -50,3 +50,4 @@ vmxnet3-repair-memory-leak.patch net-allow-neigh-contructor-functions-ability-to-modify-the-primary_key.patch ipv6-fix-udpv6-sendmsg-crash-caused-by-too-small-mtu.patch ipv4-make-neigh-lookup-keys-for-loopback-point-to-point-devices-be-inaddr_any.patch +hrtimer-reset-hrtimer-cpu-base-proper-on-cpu-hotplug.patch