[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tip-e9afe9e1b3fdbd56cca53959a2519e70db9c8095@git.kernel.org>
Date: Sat, 17 Oct 2009 09:56:49 GMT
From: tip-bot for Masami Hiramatsu <mhiramat@...hat.com>
To: linux-tip-commits@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, ananth@...ibm.com, hpa@...or.com,
mingo@...hat.com, fweisbec@...il.com, tglx@...utronix.de,
mhiramat@...hat.com, mingo@...e.hu
Subject: [tip:perf/probes] kprobes/x86: Call BUG() when reentering probe into KPROBES_HIT_SS
Commit-ID: e9afe9e1b3fdbd56cca53959a2519e70db9c8095
Gitweb: http://git.kernel.org/tip/e9afe9e1b3fdbd56cca53959a2519e70db9c8095
Author: Masami Hiramatsu <mhiramat@...hat.com>
AuthorDate: Thu, 27 Aug 2009 13:22:58 -0400
Committer: Frederic Weisbecker <fweisbec@...il.com>
CommitDate: Sun, 30 Aug 2009 03:08:26 +0200
kprobes/x86: Call BUG() when reentering probe into KPROBES_HIT_SS
Call BUG() when a probe have been hit on the way of kprobe processing
path, because that kind of probes are currently unrecoverable
(recovering it will cause an infinite loop and stack overflow).
The original code seems to assume that it's caused by an int3
which another subsystem inserted on out-of-line singlestep buffer if
the hitting probe is same as current probe. However, in that case,
int3-hitting-address is on the out-of-line buffer and should be
different from first (current) int3 address.
Thus, I decided to remove the code.
I also removes arch_disarm_kprobe() because it will involve other stuffs
in text_poke().
Signed-off-by: Masami Hiramatsu <mhiramat@...hat.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@...ibm.com>
Cc: Ingo Molnar <mingo@...e.hu>
LKML-Reference: <20090827172258.8246.61889.stgit@...alhost.localdomain>
Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
---
arch/x86/kernel/kprobes.c | 26 ++++++++++----------------
1 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index ecee3d2..e0fb615 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -482,22 +482,16 @@ static int __kprobes reenter_kprobe(struct kprobe *p, struct pt_regs *regs,
kcb->kprobe_status = KPROBE_REENTER;
break;
case KPROBE_HIT_SS:
- if (p == kprobe_running()) {
- regs->flags &= ~X86_EFLAGS_TF;
- regs->flags |= kcb->kprobe_saved_flags;
- return 0;
- } else {
- /* 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 BUG or we'll continue in an endless
- * reentering loop and eventually a stack overflow.
- */
- arch_disarm_kprobe(p);
- dump_kprobe(p);
- BUG();
- }
+ /* 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 BUG or we'll continue in an endless reentering loop
+ * and eventually a stack overflow.
+ */
+ printk(KERN_WARNING "Unrecoverable kprobe detected at %p.\n",
+ p->addr);
+ dump_kprobe(p);
+ BUG();
default:
/* impossible cases */
WARN_ON(1);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists