Messages in this thread | | | Subject | Re: [RFC PATCH -tip 0/9]ftrace, kprobes: Ftrace-based kprobe optimization | From | Steven Rostedt <> | Date | Fri, 01 Jun 2012 10:20:27 -0400 |
| |
On Fri, 2012-06-01 at 22:36 +0900, Masami Hiramatsu wrote:
> OK, so I've introduced new noprobe tag and replaced __kprobes > with it. And now __kprobes tag which is a combination of noprobe > and notrace, means that the function is not probed and it can be > called from kprobe handler. (thus user must use this with their > handlers and functions which will be used from the handlers) > And also most of __kprobes tags are replaced by noprobe only.
You still haven't answered my question. Why can't function tracer still trace these? If kprobes does not allow it to be probed, it should not interfere with your code. But normal function tracing should still allow these.
I still do not understand why you need to add 'notrace' at all.
> This means that you can trace those by function tracer :) > > BTW, currently kprobes allows user cases pagefault in their > handler (kprobe.fault_handler will handle it). I guess that > can cause some problem with ftrace, isn't it? If so, I need > to deny a kprobe using ftrace if it has fault_handler.
As long as there's recursion protection you are fine. In fact, I may add recursion protection within the assembly itself, that will make all function tracing safe. (does not solve the breakpoint bug from the other thread, but will solve most other things). In fact, this may allow us to remove notraces that were added because of recursion issues.
-- Steve
| |