* H. Peter Anvin (hpa@xxxxxxxxx) wrote: > Mathieu Desnoyers wrote: > > * H. Peter Anvin (hpa@xxxxxxxxx) wrote: > >> Mathieu Desnoyers wrote: > >>> As the maintainer of the out-of-tree LTTng tracer, which hooks in the > >>> page fault handler with tracepoints, and which can build almost entirely > >>> as modules, I am very tempted to argue that having the nmi-code entirely > >>> robust wrt in-kernel page faults would be a very-nice-to-have feature. > >>> > >> I doubt that is ever going to be reliable, due to reentrancy issues. > >> > >> -hpa > > > > Do you mean the page fault handler code is no ever going to be reliable > > or the tracer code ? > > > > I spent a great deal of effort making LTTng lockless and reentrant wrt > > NMIs. It would be great if the low-level kernel exception handlers would > > do the same, therefore I would not have to isolate the tracer from the > > kernel as I currently do. Well, I would still continue to isolate the > > tracer from the kernel, but at least I would not have to spend as much > > effort controlling what exceptions and faults paths the tracer is > > executing. > > > > So instead you want to core kernel to do your work for you? > I'm just thinking that touching or not vmalloc'd areas should not be the first thing that comes into the mind of someone willing to write a nmi-hooking tracer or oprofile module. As far as just me and LTTng are concerned, it's already dealt with. I'm just saying that having to deal with that at the tracer or profiler module level is ugly. So basically, in order to let tracer/profiler modules be more solid, yes, I think the core kernel should do that work if it does not involve any significant performance degradation. Especially due to the hard-to-reproduce and hard-to-debug nature of problems caused by such races. Mathieu > -hpa > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|