Fix: work-around upstream Linux timekeeping bug

Linux commit 27727df240c7 ("Avoid taking lock in NMI path with
CONFIG_DEBUG_TIMEKEEPING"), changed the logic to open-code
the timekeeping_get_ns() function, but forgot to include
the unit conversion from cycles to nanoseconds, breaking the
function's output, which impacts LTTng.

The following kernel versions are affected: 4.8, 4.7.4+, 4.4.20+,
4.1.32+

We expect that the upstream fix will reach the master and stable
branches timely before the next releases, so we use 4.8.1, 4.7.7,
4.4.24, and 4.1.34 as upper bounds (exclusive).

Fall-back to the non-NMI-safe trace clock for those kernel versions.
We simply discard events from NMI context with a in_nmi() check,
as we did before Linux 3.17.

Link: http://lkml.kernel.org/r/1475636148-26539-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

diff --git a/wrapper/trace-clock.h b/wrapper/trace-clock.h
index ad600ddce31fc8c1a1823d5a21a9c5d3bf029c61..001b4f404298f55c77784c8f256905192dbbd2d0 100644 (file)
--- a/wrapper/trace-clock.h
+++ b/wrapper/trace-clock.h
@@ -44,7 +44,16 @@
 #error "Linux kernels 3.10 and 3.11 introduce a deadlock in the timekeeping subsystem. Fixed by commit 7bd36014460f793c19e7d6c94dab67b0afcfcb7f \"timekeeping: Fix HRTICK related deadlock from ntp lock changes\" in Linux."
 #endif
 
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,17,0))
+/*
+ * Upstream Linux commit 27727df240c7 ("Avoid taking lock in NMI path with
+ * CONFIG_DEBUG_TIMEKEEPING") introduces a buggy ktime_get_mono_fast_ns().
+ * This is fixed by patch "timekeeping: Fix __ktime_get_fast_ns() regression".
+ */
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,17,0) \
+       && !LTTNG_KERNEL_RANGE(4,8,0, 4,8,1) \
+       && !LTTNG_KERNEL_RANGE(4,7,4, 4,7,7) \
+       && !LTTNG_KERNEL_RANGE(4,4,20, 4,4,24) \
+       && !LTTNG_KERNEL_RANGE(4,1,32, 4,1,34))
 
 DECLARE_PER_CPU(local_t, lttng_last_tsc);