Hi, Masami - masami.hiramatsu.pt wrote:
> [...] > >> [...] Then, I'd like to propose this new whitelist feature in > >> kprobe-tracer (not raw kprobe itself). And a sysctl knob for > >> disabling the whitelist. That knob will be > >> /proc/sys/debug/kprobe-event-whitelist and disabling it will mark > >> kernel tainted so that we can check it from bug reports. > > > > How would one assemble a reliable whitelist, if we haven't fully > > characterized the problems that make the blacklist necessary? > > As I said, we can use function graph tracer's list as the whitelist, > since it doesn't include any functions invoked from ftrace's event > handler. (Note that I don't mention the Systemtap or other user here) > > Whitelist is just for keeping the people away from the quantitative > issue, who just want to trace their subsystems except for ftrace. > [...] Would you plan to limit kprobes (or just the perf-probe frontend) to only function-entries also? If not, and if intra-function statement-granularity kprobes remain allowed within a function-granularity whitelist, then you might still have those "quantitative" problems. Even worse, kprobes robustness problems can bite even with a small whitelist, unless you can test the countless subset selections cartesian-product the aggrevating factors (like other tracing facilities being in use at the same time, limited memory, high irq rates, debugging sessions, architectures, whatever). > [...] For the long term solution, I think we can introduce some > kind of performance gatekeeper as systemtap does. Counting the > miss-hit rate per second and if it go over a threshold, disable next > miss-hit (or most miss-hit) probe (as OOM killer does). That would make sense, but again it would not help deal with kprobes robustness (in the kernel-crashing rather than kernel-slowdown sense). - FChE -- 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/
