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: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Ingo Molnar <mingo at kernel dot org>
- Cc: 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: Wed, 11 Dec 2013 11:12:26 +0900
- 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> <20131205102127 dot GA19923 at gmail dot com> <52A137B6 dot 6030307 at hitachi dot com> <20131210152811 dot GA1195 at gmail dot com>
(2013/12/11 0:28), Ingo Molnar wrote:
>
> * 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.
Sorry for confusion, it should be "the annotation helps us to solves
only for qualitative issue". It's my miss...
>>> 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?
The kprobe has recursion detector, but it is detected in the kprobe
exception(int3) handler, this means that if we put a probe before
detecting the recursion, we'll do an infinite recursion.
And also, even if we can detect the recursion, we can't stop the
kernel, we need to skip the probe. This means that we need to recover
to the main execution path by doing single step. As you may know,
since the single stepping involves the debug exception, we have to
avoid proving on that path too. Or we'll have an infinite recursion
again.
This is the basic reason why the __kprobes annotation is introduced.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com