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
142 Kretprobe entry-handler
145 Kretprobes also provides an optional user-specified handler which runs
148 function entry is hit, the user-defined entry_handler, if any, is invoked.
151 returns a non-zero error then Kprobes leaves the return address as is, and
156 may also specify per return-instance private data to be part of each
170 --------------------------------
173 is automatically set 'y' on x86/x86-64, non-preemptive kernel) and
175 sysctl(8)), Kprobes tries to reduce probe-hit overhead by using a jump
182 Kprobes inserts an ordinary, breakpoint-based kprobe at the specified
191 - Kprobes verifies that the region that will be replaced by the jump
196 - Kprobes analyzes the entire function and verifies that there is no
199 - the function contains no indirect jump;
200 - the function contains no instruction that causes an exception (since
202 optimized region -- Kprobes checks the exception tables to verify this);
203 - there is no near jump to the optimized region (other than to the first
206 - For each instruction in the optimized region, Kprobes verifies that
215 - code to push the CPU's registers (emulating a breakpoint trap)
216 - a call to the trampoline code which calls user's probe handlers.
217 - code to restore registers
218 - the instructions from the optimized region
219 - a jump back to the original execution path.
221 Pre-optimization
227 - The probe has a post_handler.
228 - Other instructions in the optimized region are probed.
229 - The probe is disabled.
236 optimizing list, and kicks the kprobe-optimizer workqueue to optimize
237 it. If the to-be-optimized probepoint is hit before being optimized,
240 -- thus at least avoiding the single-step.
245 The Kprobe-optimizer doesn't insert the jump instruction immediately;
253 After that, the Kprobe-optimizer calls stop_machine() to replace
273 .. [4] This optimization-safety checking may be replaced with the
274 stop-machine method that ksplice uses for supporting a CONFIG_PREEMPT=y
280 path by changing regs->ip and returning 1. However, when the probe
285 - Specify an empty function for the kprobe's post_handler.
289 - Execute 'sysctl -w debug.kprobes_optimization=n'
294 ---------
315 - i386 (Supports jump optimization)
316 - x86_64 (AMD-64, EM64T) (Supports jump optimization)
317 - ppc64
318 - sparc64 (Return probes not yet implemented.)
319 - arm
320 - ppc
321 - mips
322 - s390
323 - parisc
324 - loongarch
325 - riscv
332 "General architecture-dependent options".
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 hit, Kprobes
366 calls kp->pre_handler. After the probed instruction is single-stepped, Kprobe
367 calls kp->post_handler. Any or all handlers can be NULL. If kp->flags is set
379 (64-bit powerpc intricacies such as function descriptors are handled
387 specified, kprobe registration will fail with -EINVAL.
395 User's pre-handler (kp->pre_handler)::
405 User's post-handler (kp->post_handler)::
416 ------------------
424 rp->kp.addr. When that function returns, Kprobes calls rp->handler.
425 You must set rp->maxactive appropriately before you call
431 User's return-probe handler (rp->handler)::
442 - ret_addr: the return address
443 - rp: points to the corresponding kretprobe object
444 - task: points to the corresponding task struct
445 - data: points to per return-instance private data; see "Kretprobe
446 entry-handler" for details.
455 ------------------
472 ----------------
485 - kps/rps: an array of pointers to ``*probe`` data structures
486 - num: the number of the array entries.
494 ------------------
512 --------------
524 -------------
547 The register_*probe functions will return -EINVAL if you attempt
552 If you install a probe in an inline-able function, Kprobes makes
558 -- e.g., by modifying kernel data structures, or by modifying the
566 each other -- e.g., probing printk() and then calling printk() from a
571 As of Linux v2.6.15-rc1, multiple handlers (or multiple instances of
580 disabled on x86/x86-64). In any case, your handler should not yield
604 return -EINVAL.
606 On x86/x86-64, since the Jump Optimization of Kprobes modifies
608 explain it, we introduce some terminology. Imagine a 3-instruction
609 sequence consisting of a two 2-byte instructions and one 3-byte
616 [-2][-1][0][1][2][3][4][5][6][7]
618 [<- DCR ->]
619 [<- JTPR ->]
628 The instructions in DCR are copied to the out-of-line buffer
630 a 5-byte jump instruction. So there are several limitations.
637 Anyway, these limitations are checked by the in-kernel instruction
645 probepoint repeatedly, firing a simple handler each time, reports 1-2
646 million hits per second, depending on the architecture. A return-probe
647 hit typically takes 50-75% longer than a kprobe hit.
666 ------------------------
671 k = unoptimized kprobe, b = boosted (single-step skipped), o = optimized kprobe,
677 x86-64: Intel(R) Xeon(R) E5410, 2.33GHz, 4656.90 bogomips
684 programming interface for probe-based instrumentation. Try it out.
687 d. User-space probes.
707 - Use trace-event to trace target function with arguments.
709 trace-event is a low-overhead (and almost no visible overhead if it
715 - https://lwn.net/Articles/379903/
716 - https://lwn.net/Articles/381064/
717 - https://lwn.net/Articles/383362/
719 - Use ftrace dynamic events (kprobe event) with perf-probe.
723 by using perf-probe and set up new event to trace it.
727 - Documentation/trace/kprobetrace.rst
728 - Documentation/trace/events.rst
729 - tools/perf/Documentation/perf-probe.txt
745 The second column identifies the type of probe (k - kprobe and r - kretprobe)
753 marked with [OPTIMIZED]. If the probe is ftrace-based, it is marked with
769 /proc/sys/debug/kprobes-optimization: Turn kprobes optimization ON/OFF.
787 - https://lwn.net/Articles/132196/
788 - https://www.kernel.org/doc/ols/2006/ols2006v2-pages-109-124.pdf