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 (file)
index 0000000..d383d35
--- /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 <tglx@linutronix.de>
+Date: Fri, 26 Jan 2018 14:54:32 +0100
+Subject: hrtimer: Reset hrtimer cpu base proper on CPU hotplug
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <paulmck@linux.vnet.ibm.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Sebastian Sewior <bigeasy@linutronix.de>
+Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
+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 <bigeasy@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 09f54f2c7713c5cb2d7737375464c07ce5f03497..3c63f07cf4ba582b1fc85d535b63b06b0b9c6b2d 100644 (file)
--- 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