This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: Ingo Molnar <mingo at kernel dot org>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Sandeepa Prabhu <sandeepa dot prabhu at linaro dot org>, x86 at kernel dot org, lkml <linux-kernel at vger dot kernel dot org>, "Steven Rostedt (Red Hat)" <rostedt at goodmis dot org>, systemtap at sourceware dot org, "David S. Miller" <davem at davemloft dot net>
- Date: Thu, 05 Dec 2013 09:49:04 -0500
- Subject: Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
- Authentication-results: sourceware.org; auth=none
- References: <20131204012841 dot 22118 dot 82992 dot stgit at kbuild-fedora dot novalocal> <20131204084551 dot GA31772 at gmail dot com> <529FBA71 dot 6070107 at hitachi dot com>
Hi, Masami -
masami.hiramatsu.pt wrote:
> [...]
> For the safeness of kprobes, I have an idea; introduce a whitelist
> for dynamic events. AFAICS, the biggest unstable issue of kprobes
> comes from putting *many* probes on the functions called from tracers.
Why do you think so? We have had problems with single kprobes in the
"wrong" spot. The main reason I showed spraying them widely is to get
wide coverage with minimal information/effort, not to suggest that the
number of concurrent probes per se is a problem. (We have had
systemtap scripts probing some areas of the kernel with thousands of
active kprobes, e.g. for statement-by-statement variable-watching
jobs, and these have worked fine.)
> It doesn't crash the kernel but slows down so much, because every
> probes hit many other nested miss-hit probes.
(kprobes does have code to detect & handle reentrancy.)
> This gives us a big performance impact. [...]
Sure, but I'd expect to see pure slowdowns show their impact with
time-related problems like watchdogs firing or timeouts.
> [...] 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?
- FChE