When this probe is hit, Kprobes replace the saved return address with that of the registered jprobe handler, jprintk. It then copies a portion of the stack and returns, thus passing control to jprintk with printk 's argument list. A return probe or a kretprobe in Kprobes terminology is another specialized Kprobes helper. It eases the work of inserting a kprobe when you need to probe a function's return point. If you use vanilla Kprobes to investigate return points, you might need to register them at multiple places because a function can return via multiple code paths.
However, if you use return probes, you need to insert only one kretprobe, rather than register, say, 20 Kprobes to cover a function's 20 return paths. A single kretprobe is sufficient to alert you about failures, irrespective of the associated code path.
When this probe gets hit, this internal kprobe handler replaces the function return address with that of a special routine called a trampoline in Kprobes terminology. Kprobes has its limitations.
Some of them are obvious. You won't, for example, see desired results if you insert a kprobe inside an inline function. And, of course, you can't probe Kprobes code. Kprobes are more useful for applying probes inside the base kernel.
If the subject code is part of a dynamically loadable module, you might as well rewrite and recompile your module rather than write and compile a new module to "kprobe" it. However, you might still want to use Kprobes if bringing down the module is not acceptable. There are less-obvious limitations, too. Optimizations are done at compile time, whereas Kprobes are inserted during runtime.
So, the effect of inserting instructions via Kprobes is not equivalent to adding code in the original source files. For example, the buggy code snippet.
So, you can't easily use Kprobes if you want to sneak in between those two lines of C code, allocate a word of memory, point integerp to the allocated word, and circumvent a kernel crash. Kernel Probes Kernel probes can intrude into a kernel function and extract debug information or apply a medicated patch.
Kprobes Kprobes can save you the trouble of building and booting a debug kernel by providing capabilities to dynamically dump kernel data structures or insert code into a running kernel.
To insert a kprobe inside a kernel function, follow these steps: 1. In particular, you can probe interrupt handlers. Known exceptions are discussed in this section. If you install a probe in an inline-able function, Kprobes makes no attempt to chase down all inline instances of the function and install probes there.
A probe handler can modify the environment of the probed function -- e. So Kprobes can be used, for example, to install a bug fix or to inject faults for testing. Kprobes, of course, has no way to distinguish the deliberately injected faults from the accidental ones. Don't drink and probe. Kprobes makes no attempt to prevent probe handlers from stepping on each other -- e. If a probe handler hits a probe, that second probe's handlers won't be run in that instance, and the kprobe.
As of Linux v2. Kprobes does not use mutexes or allocate memory except during registration and unregistration. Probe handlers are run with preemption disabled. Depending on the architecture, handlers may also run with interrupts disabled. In any case, your handler should not yield the CPU e.
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. In such a case, a line: kretprobe BUG! With this information, one will be able to correlate the exact instance of the kretprobe that caused the problem. 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.
Specifically, a benchmark that hits the same probepoint repeatedly, firing a simple handler each time, reports million hits per second, depending on the architecture. When you have a return probe set on a function, adding a kprobe at the entry to that function adds essentially no overhead.
Here are sample overhead figures in usec for different architectures. TODO a. Try it out. Kernel return probes for sparc Support for other architectures.
User-space probes. Watchpoint probes which fire on data references. Some messages may be suppressed if syslogd is configured to eliminate duplicate messages. If the probed function belongs to a module, the module name is also specified. Probing trapping such functions can cause a recursive trap e. Kprobes manages such functions as a blacklist. Kprobes checks the given probe address against the blacklist and rejects registering it, if the given address is in the blacklist. Any or all handlers can be NULL.
The following will now work:. This field is used to calculate the probepoint. Called with p pointing to the kprobe associated with the breakpoint, and regs pointing to the struct containing the registers saved when the breakpoint was hit. Removes the specified probe. The unregister function can be called at any time after the probe has been registered. If the functions find an incorrect probe ex.
Registers each of the num probes in the specified array. You have to allocate or define an array of pointers and set all of the array entries before using these functions. If the functions find some incorrect probes ex. However, other probes in the array are unregistered correctly. You must specify the probe which has been registered. Kprobes allows multiple probes at the same address. 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. If you install a probe in an inline-able function, Kprobes makes no attempt to chase down all inline instances of the function and install probes there.
A probe handler can modify the environment of the probed function — e. So Kprobes can be used, for example, to install a bug fix or to inject faults for testing. Kprobes, of course, has no way to distinguish the deliberately injected faults from the accidental ones.
Kprobes makes no attempt to prevent probe handlers from stepping on each other — e. As of Linux v2. Probe handlers are run with preemption disabled or interrupt disabled, which depends on the architecture and optimization state.
In any case, your handler should not yield the CPU e. 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. In such a case, a line: kretprobe BUG! With this information, one will be able to correlate the exact instance of the kretprobe that caused the 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. To explain it, we introduce some terminology. Imagine a 3-instruction sequence consisting of a two 2-byte instructions and one 3-byte instruction.
The instructions in DCR are copied to the out-of-line buffer of the kprobe, because the bytes in DCR are replaced by a 5-byte jump instruction. So there are several limitations.
0コメント