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

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

(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 :-(

However, even though, some parts of code can be shared among them
and it will simplify their implementations.

>>>> The cons:
>>>> - Native kprobes users will be disappointed... anyway, they just need to
>>>>   move their probes to the next instruction (usually addr+=5 is OK).
>>>
>>> I've been told that doing the addr+=5 (which is also arch specific) can
>>> break things for other tools.
>>
>> As I told in previous mail, I think kprobes can do that transparently.
>
> Yeah, it could, but I'm afraid this may need to be done differently for
> every arch. If I'm working on getting this code to work for ftrace,
> which will require modifying ever arch as well, kprobes can get the
> changes for free.

I guess that anyway it should be done (at least, carefully checked)
for every arch.

Thank you,


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