On 3/12/15 9:23 AM, Steven Rostedt wrote:
On Thu, 12 Mar 2015 09:18:34 -0700
Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote:
You've so far tried very hard to not get into tracing; and then you call
rcu_read_lock() :-)
So either document why this isn't a problem, provide
rcu_read_lock_notrace() or switch to RCU-sched and thereby avoid the
problem.
I don't see the problem.
I actually do turn on func and func_graph tracers from time to time to
debug bpf core itself. Why would tracing interfere with anything that
this patch is doing? When we're inside tracing processing, we need to
use only _notrace() helpers otherwise recursion will hurt, but this
code is not invoked from there. It's called from
kprobe_ftrace_handler|kprobe_int3_handler->kprobe_dispatcher->
kprobe_perf_func->trace_call_bpf which all are perfectly traceable.
Probably my copy paste of preempt_disable_notrace() line from
stack_trace_call() became source of confusion? I believe
normal preempt_disable() here will be just fine.
It's actually redundant too, since preemption is disabled by kprobe
anyway. Please help me understand what I'm missing.
As Peter stated, "You've so far tried very hard to not get into
tracing", which the preempt_disable_notrace() is the source of confusion.
Just remove the _notrace() part, as it doesn't make sense to have part
not traced, and other parts traced for no apparent reason.
sure. consider it done. should I respin right away or you can review
the rest?
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
