Re: [PATCH 0/5][RFC] kprobes/ftrace: Have kprobes use ftrace on ftrace nops

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

(2011/08/14 11:58), Steven Rostedt wrote:
> On Sat, 2011-08-13 at 19:09 +0900, Masami Hiramatsu wrote:
>> (2011/08/12 22:08), Steven Rostedt wrote:
>>> On Fri, 2011-08-12 at 11:57 +0900, Masami Hiramatsu wrote:
>>>
>>>> I don't think it won't work. It can work but on a long way.
>>>> Could you tell me your "bigger ideas"? Perhaps, we are on the different
>>>> way but aim to same goal.
>>>
>>> Part of the bigger ideas is to have things like function graph tracing
>>> use this, as it will simplify the entry.S code. There's other things
>>> that may come out of this too.
>>
>> Hmm, I think that the current function graph tracing implementation
>> is more scalable than kretprobes, because kretprobe requires
>> spinlock on every hit. Moreover, you can't probe NMI handler with
>> kprobe, and kprobes on irq-handler are also possible to fail
>> because of recursive-call.
>> So I don't recommend using kretprobe for function-graph tracer :-(
>
> Sorry for the confusion. My idea is not to use kretprobe with function
> graph tracer, but to use the ftrace hooks with the pt_regs and friends
> for function graph tracer instead of what it does today, which is to add
> function graph code directly into entry.S.

Ah, OK.

> The point I was making is, if I need to get ftrace function tracing
> being good enough for function graph tracer, then it should work with
> kprobes without any issues.

No, I don't think so, because kprobes user may trace a flags register or
segment registers. However, function graph tracer only needs stack
register etc. Thus, if ftrace function tracing is good enough for
kprobes handlers, it is enough for function graph tracer too.

> If I need to do the work anyway (for
> function graph tracing) then why not use it directly with kprobes
> instead of doing more hooks just in the kprobe_trace?

>From the kprobe-tracer point of view, I don't mind. I just care
about complexity, and compatibility of kprobe handlers.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com