Lines Matching +full:pre +full:- +full:packaged
29 collect debugging and performance information non-disruptively. You
41 In the typical case, Kprobes-based instrumentation is packaged as
56 Kprobes -- e.g., the difference between a pre_handler and
62 -----------------------
74 Next, Kprobes single-steps its copy of the probed instruction.
75 (It would be simpler to single-step the actual instruction in place,
80 After the instruction is single-stepped, Kprobes executes the
85 -----------------------
105 -------------
114 is an arbitrary piece of code -- typically just a nop instruction.
119 handler calls the user-specified return handler associated with the
128 pre-allocates the indicated number of kretprobe_instance objects.
130 For example, if the function is non-recursive and is called with a
132 non-recursive and can never relinquish the CPU (e.g., via a semaphore
143 Kretprobe entry-handler
146 Kretprobes also provides an optional user-specified handler which runs
149 function entry is hit, the user-defined entry_handler, if any, is invoked.
152 returns a non-zero error then Kprobes leaves the return address as is, and
157 may also specify per return-instance private data to be part of each
171 --------------------------------
174 is automatically set 'y' on x86/x86-64, non-preemptive kernel) and
176 sysctl(8)), Kprobes tries to reduce probe-hit overhead by using a jump
183 Kprobes inserts an ordinary, breakpoint-based kprobe at the specified
192 - Kprobes verifies that the region that will be replaced by the jump
197 - Kprobes analyzes the entire function and verifies that there is no
200 - the function contains no indirect jump;
201 - the function contains no instruction that causes an exception (since
203 optimized region -- Kprobes checks the exception tables to verify this);
204 - there is no near jump to the optimized region (other than to the first
207 - For each instruction in the optimized region, Kprobes verifies that
216 - code to push the CPU's registers (emulating a breakpoint trap)
217 - a call to the trampoline code which calls user's probe handlers.
218 - code to restore registers
219 - the instructions from the optimized region
220 - a jump back to the original execution path.
222 Pre-optimization
228 - The probe has a post_handler.
229 - Other instructions in the optimized region are probed.
230 - The probe is disabled.
237 optimizing list, and kicks the kprobe-optimizer workqueue to optimize
238 it. If the to-be-optimized probepoint is hit before being optimized,
241 -- thus at least avoiding the single-step.
246 The Kprobe-optimizer doesn't insert the jump instruction immediately;
254 After that, the Kprobe-optimizer calls stop_machine() to replace
274 .. [4] This optimization-safety checking may be replaced with the
275 stop-machine method that ksplice uses for supporting a CONFIG_PREEMPT=y
281 path by changing regs->ip and returning 1. However, when the probe
286 - Specify an empty function for the kprobe's post_handler.
290 - Execute 'sysctl -w debug.kprobes_optimization=n'
295 ---------
316 - i386 (Supports jump optimization)
317 - x86_64 (AMD-64, EM64T) (Supports jump optimization)
318 - ppc64
319 - ia64 (Does not support probes on instruction slot1.)
320 - sparc64 (Return probes not yet implemented.)
321 - arm
322 - ppc
323 - mips
324 - s390
325 - parisc
334 So that you can load and unload Kprobes-based instrumentation modules,
339 are set to "y", since kallsyms_lookup_name() is used by the in-kernel
344 so you can use "objdump -d -l vmlinux" to see the source-to-object
353 Here are terse, mini-man-page specifications for these functions and
355 samples/kprobes/ sub-directory for examples.
358 ---------------
365 Sets a breakpoint at the address kp->addr. When the breakpoint is
366 hit, Kprobes calls kp->pre_handler. After the probed instruction
367 is single-stepped, Kprobe calls kp->post_handler. If a fault
368 occurs during execution of kp->pre_handler or kp->post_handler,
369 or during single-stepping of the probed instruction, Kprobes calls
370 kp->fault_handler. Any or all handlers can be NULL. If kp->flags
382 (64-bit powerpc intricacies such as function descriptors are handled
390 specified, kprobe registration will fail with -EINVAL.
398 User's pre-handler (kp->pre_handler)::
408 User's post-handler (kp->post_handler)::
418 User's fault-handler (kp->fault_handler)::
425 architecture-specific trap number associated with the fault (e.g.,
430 ------------------
438 rp->kp.addr. When that function returns, Kprobes calls rp->handler.
439 You must set rp->maxactive appropriately before you call
445 User's return-probe handler (rp->handler)::
456 - ret_addr: the return address
457 - rp: points to the corresponding kretprobe object
458 - task: points to the corresponding task struct
459 - data: points to per return-instance private data; see "Kretprobe
460 entry-handler" for details.
469 ------------------
486 ----------------
499 - kps/rps: an array of pointers to ``*probe`` data structures
500 - num: the number of the array entries.
508 ------------------
526 --------------
538 -------------
561 The register_*probe functions will return -EINVAL if you attempt
566 If you install a probe in an inline-able function, Kprobes makes
572 -- e.g., by modifying kernel data structures, or by modifying the
580 each other -- e.g., probing printk() and then calling printk() from a
585 As of Linux v2.6.15-rc1, multiple handlers (or multiple instances of
594 disabled on x86/x86-64). In any case, your handler should not yield
618 return -EINVAL.
620 On x86/x86-64, since the Jump Optimization of Kprobes modifies
622 explain it, we introduce some terminology. Imagine a 3-instruction
623 sequence consisting of a two 2-byte instructions and one 3-byte
630 [-2][-1][0][1][2][3][4][5][6][7]
632 [<- DCR ->]
633 [<- JTPR ->]
642 The instructions in DCR are copied to the out-of-line buffer
644 a 5-byte jump instruction. So there are several limitations.
651 Anyway, these limitations are checked by the in-kernel instruction
659 probepoint repeatedly, firing a simple handler each time, reports 1-2
660 million hits per second, depending on the architecture. A return-probe
661 hit typically takes 50-75% longer than a kprobe hit.
680 ------------------------
685 k = unoptimized kprobe, b = boosted (single-step skipped), o = optimized kprobe,
691 x86-64: Intel(R) Xeon(R) E5410, 2.33GHz, 4656.90 bogomips
698 programming interface for probe-based instrumentation. Try it out.
701 d. User-space probes.
721 - Use trace-event to trace target function with arguments.
723 trace-event is a low-overhead (and almost no visible overhead if it
729 - https://lwn.net/Articles/379903/
730 - https://lwn.net/Articles/381064/
731 - https://lwn.net/Articles/383362/
733 - Use ftrace dynamic events (kprobe event) with perf-probe.
737 by using perf-probe and set up new event to trace it.
741 - Documentation/trace/kprobetrace.rst
742 - Documentation/trace/events.rst
743 - tools/perf/Documentation/perf-probe.txt
759 The second column identifies the type of probe (k - kprobe and r - kretprobe)
767 marked with [OPTIMIZED]. If the probe is ftrace-based, it is marked with
783 /proc/sys/debug/kprobes-optimization: Turn kprobes optimization ON/OFF.
801 - https://www.ibm.com/developerworks/library/l-kprobes/index.html
802 - https://www.kernel.org/doc/ols/2006/ols2006v2-pages-109-124.pdf