Re: Questions about kprobes implementation on SMP and preemptible kernels

["Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>]

On Tue, Jan 30, 2007 at 11:43:45PM -0600, Quentin Barnes wrote:
> On Mon, Jan 29, 2007 at 09:57:55AM +0530, Ananth N Mavinakayanahalli wrote:
> >On Sat, Jan 27, 2007 at 05:59:48PM -0600, Quentin Barnes wrote:
> >>On Tue, Jan 16, 2007 at 11:09:55AM +0530, Ananth N Mavinakayanahalli 
> >>wrote:
> >>>On architectures which run kprobes with interrupts enabled, its not
> >>>uncommon to have interrupts occur while we are processing a kprobe. In
> >>>fact, the kprobe reentry handling code was a byproduct of such a
> >>>scenario happening.
> >>
> >>I'm not sure I follow this point clearly enough.
> >>
> >>As far as I follow, recursion for kprobes is only handled to no more
> >>than one level when re-entered and only from a kprobe encountered
> >>in a pre- or post-handler.  In that case, kprobe_status is set to
> >>KPROBE_REENTER and the pre- and post-handlers aren't run for that
> >>one recursion level so we don't recurse yet again.
> >>
> >>If we're processing a kprobe with interrupts enabled and an
> >>interrupt fires and its handler has a kprobe, we would re-enter.  At
> >>this point, this would "work" in the sense that kprobe's pre- and
> >>post-handler would not run even though they may not contain any
> >>kprobes themselves.  Is this considered an acceptable behavior?
> >
> >Yes. At this point, you just increment struct kprobe->nmissed to
> >indicate that you missed running the handlers and move on.
> 
> I suppose.
> 
> >>If the same scenario happened above (kprobe in interrupt handler
> >>and its interrupt fired) but this time we're already nested from
> >>handling a kprobe and another kprobe in its pre- or post-handler,
> >>save_previous_kprobe() would overwrite an already active previous
> >>kprobe state.  This would seem to be a serious bug.
Yes this would seem to be a serious bug on architecture where
interrupts are not disabled when debug break ( kprobe break) instructions
are executed. AFAIK, Ia64 and PPC64 does not disable interrupts when
debug break instruction are executed(i.e interrupts are not disabled
while kprobe handlers are run). On i386 and x86_64 this is not an issues
because interrupts are disabled on execution of int3 instruction.
> >
> >Though such a scenario is eminently possible, we haven't encountered it
> >in the real world (yet :).
> 
> It doesn't matter if it's actually been been encountered or not.  An
> unexecuted bug in the code's logic is still a bug in the logic.
Yes, I do agree.

> 
> I would like to know for sure if it would happen or not though.
I was able to reproduce this bug on Ia64 with the test case.

> 
> >AFAIR, Anil had a patch to handle this
> >specific case. Not sure what the status of the patch is at the moment.
I had a patch which I had posted on lkml that did not make it since that
patch assumed that it has to fix for i386 and x86_64 along with ia64. Since
the other two arch did not needed this fix, the patch as a whole did not make it.
You can find the patch at http://sourceware.org/bugzilla # 2071


thanks,
-Anil Keshavamurthy