Re: [RFC PATCH -tip 0/9]ftrace, kprobes: Ftrace-based kprobe optimization

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

(2012/06/01 0:15), Steven Rostedt wrote:
> On Fri, 2012-06-01 at 00:01 +0900, Masami Hiramatsu wrote:
> 
>> OK, that's same as what I expected. In that case,
>> all __kprobes functions are already filtered out
>> by kprobes itself. So we don't need to set that anymore.
>>
>> Hmm, CFLAGS_REMOVE_kprobes.o can also keep kprobes from
>> function tracer. So I'd like to try to use that instead
>> of including notrace into __kprobes.
>> However, in that case, kprobe users must remove -pg from
>> their kernel modules too, and take care that they must
>> call only notrace kernel APIs...
>>
>> Perhaps, we'd better introduce new kprobe flag which allow
>> kprobe to accept new probe on ftrace, so that user can
>> explicitly understand what he will do.
> 
> Please do not make kprobe functions not allow function tracing! I *want*
> to trace these functions! For example, I trace functions in NMIs all the
> time, and I know these are prohibited by kprobes.
> 
> Why can't we function trace this? If kprobes does not trace functions
> marked with kprobes already, then it should not have any issue. Kprobes
> will only use the function tracer for what its allowed to use.

Because when I removed notrace from the __kprobes, the kernel caused
triple fault and didn't boot, even kprobes was not used.
I guess that it is because some recursive call of function tracer
has happened. So, I've added notrace to __kprobes (but it was too
widely applied).

> Do not remove -pg from anything to satisfy kprobes. It shouldn't need
> it.

But some kprobes functions will/must be called from kprobes handlers.
Those should be marked as notrace, shouldn't it?

Thank you,

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