[PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs

Ingo Molnar mingo@kernel.org
Tue Dec 10 15:28:00 GMT 2013


* Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:

> (2013/12/05 19:21), Ingo Molnar wrote:
> > 
> > * Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
> > 
> >>> So we need both a maintainable and a sane/safe solution, and I'd 
> >>> like to apply the whole thing at once and be at ease that the 
> >>> solution is round. We should have done this years ago.
> >>
> >> 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.
> > 
> > If the number of 'noprobe' annotations is expected to explode then 
> > maybe another approach should be considered.
> 
> No, since this is a "quantitative" issue, the annotation helps us.
> 
> > For example in perf we detect recursion. Could kprobes do that and 
> > detect hitting a probe while running kprobes code, and ignore it [do 
> > an early return]?
> 
> Yes, the kprobe itself already has recursion detector and it rejects
> calling handler.

So why are annotations needed at all? What can happen if an annotation 
is missing and a piece of code is probed which is also used by the 
kprobes code internally - do we crash, lock up, misbehave or handle it 
safely?

Thanks,

	Ingo



More information about the Systemtap mailing list