(2013/11/15 23:28), Frederic Weisbecker wrote: > On Fri, Nov 15, 2013 at 09:15:21AM -0500, Steven Rostedt wrote: >> On Fri, 15 Nov 2013 13:28:33 +0100 >> Peter Zijlstra <pet...@infradead.org> wrote: >> >>> On Fri, Nov 15, 2013 at 10:16:18AM +0900, Masami Hiramatsu wrote: >>>> 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 :) >>> >>> Ah, ok, so that would avoid the worst problems. Good. Should we still >>> mark the entire perf swevent path as __kprobes just to be sure? >> >> I wouldn't unless we can prove that it breaks. It's sometimes nice to >> be able to debug the debugging facilities with the debugging >> facilities ;-) > > Even with the existing __kprobes annotations, I'm sure we can find many ways > to > break the kernel. > > We can reproduce that bug with irq_work recursion with setting a kprobe in > the end of the irq_work() arch low level handler for example. Or simply > somewhere in irq_exit(). > > I think we could do dangerous things with breakpoints as well. Setting > breakpoints > in do_debug() or stuffs like that. > > So keeping up with __kprobes annotations to every potential dangerous site > is not viable IMHO. It's important to maintain basic sanity with tagging sites > that are used by kprobes itself but we can't really prevent from any issue. > > At some point it's up to the user to know what he's doing and avoid recursion. > As long as kprobes can be set only by root.
Hmm, it would be better to add some documentation how users can avoid such thing. > OTOH it would be nice to detect these kind of behaviour (thinking about > irq_work for > example) and warn when something wrong is suspected. Agreed. FYI, kprobes has a recursion detection counter and it is reported via debugfs/tracing/kprobe_profile :) 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/
