4.9-stable patches

added patches:
	ftrace-x86-fix-triple-fault-with-graph-tracing-and-suspend-to-ram.patch

diff --git a/queue-4.9/ftrace-x86-fix-triple-fault-with-graph-tracing-and-suspend-to-ram.patch b/queue-4.9/ftrace-x86-fix-triple-fault-with-graph-tracing-and-suspend-to-ram.patch
new file mode 100644 (file)
index 0000000..82d5e4f
--- /dev/null
+++ b/queue-4.9/ftrace-x86-fix-triple-fault-with-graph-tracing-and-suspend-to-ram.patch
@@ -0,0 +1,82 @@
+From 34a477e5297cbaa6ecc6e17c042a866e1cbe80d6 Mon Sep 17 00:00:00 2001
+From: Josh Poimboeuf <jpoimboe@redhat.com>
+Date: Thu, 13 Apr 2017 17:53:55 -0500
+Subject: ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram
+
+From: Josh Poimboeuf <jpoimboe@redhat.com>
+
+commit 34a477e5297cbaa6ecc6e17c042a866e1cbe80d6 upstream.
+
+On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable function
+graph tracing and then suspend to RAM, it will triple fault and reboot when
+it resumes.
+
+The first fault happens when booting a secondary CPU:
+
+startup_32_smp()
+  load_ucode_ap()
+    prepare_ftrace_return()
+      ftrace_graph_is_dead()
+        (accesses 'kill_ftrace_graph')
+
+The early head_32.S code calls into load_ucode_ap(), which has an an
+ftrace hook, so it calls prepare_ftrace_return(), which calls
+ftrace_graph_is_dead(), which tries to access the global
+'kill_ftrace_graph' variable with a virtual address, causing a fault
+because the CPU is still in real mode.
+
+The fix is to add a check in prepare_ftrace_return() to make sure it's
+running in protected mode before continuing.  The check makes sure the
+stack pointer is a virtual kernel address.  It's a bit of a hack, but
+it's not very intrusive and it works well enough.
+
+For reference, here are a few other (more difficult) ways this could
+have potentially been fixed:
+
+- Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging
+  is enabled.  (No idea what that would break.)
+
+- Track down load_ucode_ap()'s entire callee tree and mark all the
+  functions 'notrace'.  (Probably not realistic.)
+
+- Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu()
+  or __cpu_up(), and ensure that the pause facility can be queried from
+  real mode.
+
+Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>
+Cc: linux-acpi@vger.kernel.org
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Len Brown <lenb@kernel.org>
+Link: http://lkml.kernel.org/r/5c1272269a580660703ed2eccf44308e790c7a98.1492123841.git.jpoimboe@redhat.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/ftrace.c |   12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/arch/x86/kernel/ftrace.c
++++ b/arch/x86/kernel/ftrace.c
+@@ -983,6 +983,18 @@ void prepare_ftrace_return(unsigned long
+       unsigned long return_hooker = (unsigned long)
+                               &return_to_handler;
+ 
++      /*
++       * When resuming from suspend-to-ram, this function can be indirectly
++       * called from early CPU startup code while the CPU is in real mode,
++       * which would fail miserably.  Make sure the stack pointer is a
++       * virtual address.
++       *
++       * This check isn't as accurate as virt_addr_valid(), but it should be
++       * good enough for this purpose, and it's fast.
++       */
++      if (unlikely((long)__builtin_frame_address(0) >= 0))
++              return;
++
+       if (unlikely(ftrace_graph_is_dead()))
+               return;
+ 

diff --git a/queue-4.9/series b/queue-4.9/series
index 3fcd0b916f49cb04dddb5c2798fd4214ce7439a2..369d228c957d4ccac757ba636dd891b833380a95 100644 (file)
--- a/queue-4.9/series
+++ b/queue-4.9/series
@@ -51,3 +51,4 @@ ceph-fix-recursion-between-ceph_set_acl-and-__ceph_setattr.patch
 macsec-avoid-heap-overflow-in-skb_to_sgvec.patch
 net-can-usb-gs_usb-fix-buffer-on-stack.patch
 arcv2-save-r30-on-kernel-entry-as-gcc-uses-it-for-code-gen.patch
+ftrace-x86-fix-triple-fault-with-graph-tracing-and-suspend-to-ram.patch