4.4-stable patches

added patches:
	timekeeping-fix-__ktime_get_fast_ns-regression.patch

diff --git a/queue-4.4/series b/queue-4.4/series
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..e1f5408df023da3d16bfe88714ed940f18750b13 100644 (file)
--- a/queue-4.4/series
+++ b/queue-4.4/series
@@ -0,0 +1 @@
+timekeeping-fix-__ktime_get_fast_ns-regression.patch

diff --git a/queue-4.4/timekeeping-fix-__ktime_get_fast_ns-regression.patch b/queue-4.4/timekeeping-fix-__ktime_get_fast_ns-regression.patch
new file mode 100644 (file)
index 0000000..f931f9c
--- /dev/null
+++ b/queue-4.4/timekeeping-fix-__ktime_get_fast_ns-regression.patch
@@ -0,0 +1,84 @@
+From 58bfea9532552d422bde7afa207e1a0f08dffa7d Mon Sep 17 00:00:00 2001
+From: John Stultz <john.stultz@linaro.org>
+Date: Tue, 4 Oct 2016 19:55:48 -0700
+Subject: timekeeping: Fix __ktime_get_fast_ns() regression
+
+From: John Stultz <john.stultz@linaro.org>
+
+commit 58bfea9532552d422bde7afa207e1a0f08dffa7d upstream.
+
+In commit 27727df240c7 ("Avoid taking lock in NMI path with
+CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code
+the timekeeping_get_ns() function, but I forgot to include
+the unit conversion from cycles to nanoseconds, breaking the
+function's output, which impacts users like perf.
+
+This results in bogus perf timestamps like:
+ swapper     0 [000]   253.427536:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.426573:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.426687:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.426800:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.426905:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.427022:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.427127:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.427239:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.427346:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   254.427463:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]   255.426572:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+
+Instead of more reasonable expected timestamps like:
+ swapper     0 [000]    39.953768:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.064839:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.175956:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.287103:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.398217:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.509324:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.620437:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.731546:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.842654:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    40.953772:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+ swapper     0 [000]    41.064881:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
+
+Add the proper use of timekeeping_delta_to_ns() to convert
+the cycle delta to nanoseconds as needed.
+
+Thanks to Brendan and Alexei for finding this quickly after
+the v4.8 release. Unfortunately the problematic commit has
+landed in some -stable trees so they'll need this fix as
+well.
+
+Many apologies for this mistake. I'll be looking to add a
+perf-clock sanity test to the kselftest timers tests soon.
+
+Fixes: 27727df240c7 "timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING"
+Reported-by: Brendan Gregg <bgregg@netflix.com>
+Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
+Tested-and-reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Signed-off-by: John Stultz <john.stultz@linaro.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Link: http://lkml.kernel.org/r/1475636148-26539-1-git-send-email-john.stultz@linaro.org
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/time/timekeeping.c |    7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/kernel/time/timekeeping.c
++++ b/kernel/time/timekeeping.c
+@@ -385,8 +385,11 @@ static __always_inline u64 __ktime_get_f
+               tkr = tkf->base + (seq & 0x01);
+               now = ktime_to_ns(tkr->base);
+ 
+-              now += clocksource_delta(tkr->read(tkr->clock),
+-                                       tkr->cycle_last, tkr->mask);
++              now += timekeeping_delta_to_ns(tkr,
++                              clocksource_delta(
++                                      tkr->read(tkr->clock),
++                                      tkr->cycle_last,
++                                      tkr->mask));
+       } while (read_seqcount_retry(&tkf->seq, seq));
+ 
+       return now;