Skip to content

Commit b506a9d

Browse files
qbarnesIngo Molnar
authored andcommitted
x86: code clarification patch to Kprobes arch code
When developing the Kprobes arch code for ARM, I ran across some code found in x86 and s390 Kprobes arch code which I didn't consider as good as it could be. Once I figured out what the code was doing, I changed the code for ARM Kprobes to work the way I felt was more appropriate. I've tested the code this way in ARM for about a year and would like to push the same change to the other affected architectures. The code in question is in kprobe_exceptions_notify() which does: ==== /* kprobe_running() needs smp_processor_id() */ preempt_disable(); if (kprobe_running() && kprobe_fault_handler(args->regs, args->trapnr)) ret = NOTIFY_STOP; preempt_enable(); ==== For the moment, ignore the code having the preempt_disable()/ preempt_enable() pair in it. The problem is that kprobe_running() needs to call smp_processor_id() which will assert if preemption is enabled. That sanity check by smp_processor_id() makes perfect sense since calling it with preemption enabled would return an unreliable result. But the function kprobe_exceptions_notify() can be called from a context where preemption could be enabled. If that happens, the assertion in smp_processor_id() happens and we're dead. So what the original author did (speculation on my part!) is put in the preempt_disable()/preempt_enable() pair to simply defeat the check. Once I figured out what was going on, I considered this an inappropriate approach. If kprobe_exceptions_notify() is called from a preemptible context, we can't be in a kprobe processing context at that time anyways since kprobes requires preemption to already be disabled, so just check for preemption enabled, and if so, blow out before ever calling kprobe_running(). I wrote the ARM kprobe code like this: ==== /* To be potentially processing a kprobe fault and to * trust the result from kprobe_running(), we have * be non-preemptible. */ if (!preemptible() && kprobe_running() && kprobe_fault_handler(args->regs, args->trapnr)) ret = NOTIFY_STOP; ==== The above code has been working fine for ARM Kprobes for a year. So I changed the x86 code (2.6.24-rc6) to be the same way and ran the Systemtap tests on that kernel. As on ARM, Systemtap on x86 comes up with the same test results either way, so it's a neutral external functional change (as expected). This issue has been discussed previously on linux-arm-kernel and the Systemtap mailing lists. Pointers to the by base for the two discussions: http://lists.arm.linux.org.uk/lurker/message/20071219.223225.1f5c2a5e.en.html http://sourceware.org/ml/systemtap/2007-q1/msg00251.html Signed-off-by: Quentin Barnes <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Ananth N Mavinakayahanalli <[email protected]> Acked-by: Ananth N Mavinakayahanalli <[email protected]>
1 parent 3f4380a commit b506a9d

File tree

1 file changed

+7
-4
lines changed

1 file changed

+7
-4
lines changed

arch/x86/kernel/kprobes.c

Lines changed: 7 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -44,6 +44,7 @@
4444
#include <linux/ptrace.h>
4545
#include <linux/string.h>
4646
#include <linux/slab.h>
47+
#include <linux/hardirq.h>
4748
#include <linux/preempt.h>
4849
#include <linux/module.h>
4950
#include <linux/kdebug.h>
@@ -951,12 +952,14 @@ int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
951952
ret = NOTIFY_STOP;
952953
break;
953954
case DIE_GPF:
954-
/* kprobe_running() needs smp_processor_id() */
955-
preempt_disable();
956-
if (kprobe_running() &&
955+
/*
956+
* To be potentially processing a kprobe fault and to
957+
* trust the result from kprobe_running(), we have
958+
* be non-preemptible.
959+
*/
960+
if (!preemptible() && kprobe_running() &&
957961
kprobe_fault_handler(args->regs, args->trapnr))
958962
ret = NOTIFY_STOP;
959-
preempt_enable();
960963
break;
961964
default:
962965
break;

0 commit comments

Comments
 (0)