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. -- Steve -- 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
