tracing/kprobes: Dump the culprit kprobe in case of kprobe recursion

Kprobes can enter into a probing recursion, ie: a kprobe that does an
endless loop because one of its core mechanism function used during
probing is also probed itself.

This patch helps pinpointing the kprobe that raised such recursion
by dumping it and raising a BUG instead of a warning (we also disarm
the kprobe to try avoiding recursion in BUG itself). Having a BUG
instead of a warning stops the stacktrace in the right place and
doesn't pollute the logs with hundreds of traces that eventually end
up in a stack overflow.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>

1 files changed, 6 insertions, 2 deletions

diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 16ae9610f6f..ecee3d23fef 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -490,9 +490,13 @@ static int __kprobes reenter_kprobe(struct kprobe *p, struct pt_regs *regs,
                         /* A probe has been hit in the codepath leading up
                          * to, or just after, single-stepping of a probed
                          * instruction. This entire codepath should strictly
-                         * reside in .kprobes.text section. Raise a warning
-                         * to highlight this peculiar case.
+                         * reside in .kprobes.text section.
+                         * Raise a BUG or we'll continue in an endless
+                         * reentering loop and eventually a stack overflow.
                          */
+                        arch_disarm_kprobe(p);
+                        dump_kprobe(p);
+                        BUG();
                 }
         default:
                 /* impossible cases */