Messages in this thread | | | Date | Wed, 30 May 2012 16:56:25 +0900 | From | Masami Hiramatsu <> | Subject | Re: [RFC PATCH -tip 8/9] kprobes: introduce ftrace based optiomization |
| |
(2012/05/30 16:22), Ananth N Mavinakayanahalli wrote: > On Tue, May 29, 2012 at 09:49:45PM +0900, Masami Hiramatsu wrote: >> Introduce function trace based kprobes optimization. >> >> With using ftrace optimization, kprobes on the mcount calling >> address, use ftrace's mcount call instead of breakpoint. >> Farthermore, this optimization works with preemptive kernel >> not like as current jump-based optimization. Of cource, >> this feature is limited only if the probe on mcount call. > > The above paragraph doesn't parse correctly for me. Do you mean to say > if the probe is on the mcount calling address, use the jump based > approach instead of the breakpoint one? Could you please rephrase?
Right, but not use current jump-base one, but use function tracer handler directly.
So, ftrace-based optimization will be done on the kprobe at the mcount calling address, which has been replaced with a 5 byte NOP at the build-time. The ftrace-based optimization uses function-tracer handler (kernel/trace/ftrace.c) instead of int3 breakpoint trapping.
The probing behavior is like below
1. hit mcount calling address 2. call ftrace_caller -> 3. save all registers 4. call ftrace's handler (kprobe_ftrace_handler) -> 5. set up current kprobe 6. call kprobe handler <- 7. return 8. restore registers <- 9. return 10. continue to run
>> +static void __kprobes kprobe_ftrace_init(void) >> +{ >> + int ret; >> + >> + ret = register_ftrace_function(&kprobe_ftrace_ops); >> + WARN(ret < 0, "Failed to init kprobe-ftrace (%d)\n", ret); >> + >> + kprobe_ftrace_enabled = 1; > > Hmm.. is this right? kprobe_ftrace_enabled is 1 even if the init failed.
Oops, that should be a bug! thanks!
-- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |