Re: [RFC PATCH -tip 8/9] kprobes: introduce ftrace based optiomization

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

(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