summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJim Keniston <jkenisto@us.ibm.com>2006-02-14 13:53:06 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2006-02-14 16:09:34 -0800
commit8861da31e3b3e3df7b05e7b157230de3d486e53b (patch)
tree15b8874fbad4dc1170f64cd8a5be7df4eced9686
parent61b9a26ae6d308ade964db122e0e89299586422c (diff)
[PATCH] kprobes: Update Documentation/kprobes.txt
Update Documentation/kprobes.txt to reflect Kprobes enhancements and other recent developments. Acked-by: Ananth Mavinakayanahalli <mananth@in.ibm.com> Signed-off-by: Jim Keniston <jkenisto@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-rw-r--r--Documentation/kprobes.txt81
1 files changed, 42 insertions, 39 deletions
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index 0ea5a0c6e827..2c3b1eae4280 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt
@@ -136,17 +136,20 @@ Kprobes, jprobes, and return probes are implemented on the following
architectures:
- i386
-- x86_64 (AMD-64, E64MT)
+- x86_64 (AMD-64, EM64T)
- ppc64
-- ia64 (Support for probes on certain instruction types is still in progress.)
+- ia64 (Does not support probes on instruction slot1.)
- sparc64 (Return probes not yet implemented.)
3. Configuring Kprobes
When configuring the kernel using make menuconfig/xconfig/oldconfig,
-ensure that CONFIG_KPROBES is set to "y". Under "Kernel hacking",
-look for "Kprobes". You may have to enable "Kernel debugging"
-(CONFIG_DEBUG_KERNEL) before you can enable Kprobes.
+ensure that CONFIG_KPROBES is set to "y". Under "Instrumentation
+Support", look for "Kprobes".
+
+So that you can load and unload Kprobes-based instrumentation modules,
+make sure "Loadable module support" (CONFIG_MODULES) and "Module
+unloading" (CONFIG_MODULE_UNLOAD) are set to "y".
You may also want to ensure that CONFIG_KALLSYMS and perhaps even
CONFIG_KALLSYMS_ALL are set to "y", since kallsyms_lookup_name()
@@ -262,18 +265,18 @@ at any time after the probe has been registered.
5. Kprobes Features and Limitations
-As of Linux v2.6.12, Kprobes allows multiple probes at the same
-address. Currently, however, there cannot be multiple jprobes on
-the same function at the same time.
+Kprobes allows multiple probes at the same address. Currently,
+however, there cannot be multiple jprobes on the same function at
+the same time.
In general, you can install a probe anywhere in the kernel.
In particular, you can probe interrupt handlers. Known exceptions
are discussed in this section.
-For obvious reasons, it's a bad idea to install a probe in
-the code that implements Kprobes (mostly kernel/kprobes.c and
-arch/*/kernel/kprobes.c). A patch in the v2.6.13 timeframe instructs
-Kprobes to reject such requests.
+The register_*probe functions will return -EINVAL if you attempt
+to install a probe in the code that implements Kprobes (mostly
+kernel/kprobes.c and arch/*/kernel/kprobes.c, but also functions such
+as do_page_fault and notifier_call_chain).
If you install a probe in an inline-able function, Kprobes makes
no attempt to chase down all inline instances of the function and
@@ -290,18 +293,14 @@ from the accidental ones. Don't drink and probe.
Kprobes makes no attempt to prevent probe handlers from stepping on
each other -- e.g., probing printk() and then calling printk() from a
-probe handler. As of Linux v2.6.12, if a probe handler hits a probe,
-that second probe's handlers won't be run in that instance.
-
-In Linux v2.6.12 and previous versions, Kprobes' data structures are
-protected by a single lock that is held during probe registration and
-unregistration and while handlers are run. Thus, no two handlers
-can run simultaneously. To improve scalability on SMP systems,
-this restriction will probably be removed soon, in which case
-multiple handlers (or multiple instances of the same handler) may
-run concurrently on different CPUs. Code your handlers accordingly.
-
-Kprobes does not use semaphores or allocate memory except during
+probe handler. If a probe handler hits a probe, that second probe's
+handlers won't be run in that instance, and the kprobe.nmissed member
+of the second probe will be incremented.
+
+As of Linux v2.6.15-rc1, multiple handlers (or multiple instances of
+the same handler) may run concurrently on different CPUs.
+
+Kprobes does not use mutexes or allocate memory except during
registration and unregistration.
Probe handlers are run with preemption disabled. Depending on the
@@ -316,11 +315,18 @@ address instead of the real return address for kretprobed functions.
(As far as we can tell, __builtin_return_address() is used only
for instrumentation and error reporting.)
-If the number of times a function is called does not match the
-number of times it returns, registering a return probe on that
-function may produce undesirable results. We have the do_exit()
-and do_execve() cases covered. do_fork() is not an issue. We're
-unaware of other specific cases where this could be a problem.
+If the number of times a function is called does not match the number
+of times it returns, registering a return probe on that function may
+produce undesirable results. We have the do_exit() case covered.
+do_execve() and do_fork() are not an issue. We're unaware of other
+specific cases where this could be a problem.
+
+If, upon entry to or exit from a function, the CPU is running on
+a stack other than that of the current task, registering a return
+probe on that function may produce undesirable results. For this
+reason, Kprobes doesn't support return probes (or kprobes or jprobes)
+on the x86_64 version of __switch_to(); the registration functions
+return -EINVAL.
6. Probe Overhead
@@ -347,14 +353,12 @@ k = 0.77 usec; j = 1.31; r = 1.26; kr = 1.45; jr = 1.99
7. TODO
-a. SystemTap (http://sourceware.org/systemtap): Work in progress
-to provide a simplified programming interface for probe-based
-instrumentation.
-b. Improved SMP scalability: Currently, work is in progress to handle
-multiple kprobes in parallel.
-c. Kernel return probes for sparc64.
-d. Support for other architectures.
-e. User-space probes.
+a. SystemTap (http://sourceware.org/systemtap): Provides a simplified
+programming interface for probe-based instrumentation. Try it out.
+b. Kernel return probes for sparc64.
+c. Support for other architectures.
+d. User-space probes.
+e. Watchpoint probes (which fire on data references).
8. Kprobes Example
@@ -411,8 +415,7 @@ int init_module(void)
printk("Couldn't find %s to plant kprobe\n", "do_fork");
return -1;
}
- ret = register_kprobe(&kp);
- if (ret < 0) {
+ if ((ret = register_kprobe(&kp) < 0)) {
printk("register_kprobe failed, returned %d\n", ret);
return -1;
}