(2013/11/15 0:33), Peter Zijlstra wrote: > On Thu, Nov 14, 2013 at 04:23:04PM +0100, Peter Zijlstra wrote: >> /* >> + * We must dis-allow sampling irq_work_exit() because perf event sampling >> + * itself can cause irq_work, which would lead to an infinite loop; >> + * >> + * 1) irq_work_exit happens >> + * 2) generates perf sample >> + * 3) generates irq_work >> + * 4) goto 1 >> + */ >> +TRACE_EVENT_PERF_PERM(irq_work_exit, is_sampling_event(p_event) ? -EPERM : >> 0); > > And the only reason this doesn't feed fwd itself into oblivion for > irq_work_enter() is because the irq_work_list must not be empty when the > interrupt is raised, and queueing further work does not re-raise the > IPI. > > > Also, we should probably do something 'smart' for kprobes, as all of > irq_work.c and plenty of perf itself is not __kprobe marked so you're > all free to insert kprobes in the middle of perf and then attach perf to > such a thing.
Kprobes itself can detect nested call by using per-cpu current-running kprobe pointer. And if it is nested, it just skips calling handlers. Anyway, I don't recommend to probe inside the handlers, but yes, you can trace perf-handler by ftrace B). I actually traced a kprobe-bug by kprobe-tracer last night, that was amazing :) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
