Re: [RFC] Design + prototype: Multiple kprobes at an address - take2

[Ananth N Mavinakayanahalli <amavin at redhat dot com>]

Frank Ch. Eigler wrote:
> Hi -
>
>
> On Wed, Apr 06, 2005 at 10:48:21AM -0400, Ananth N Mavinakayanahalli wrote:
>
> > [...]
> > 1. I haven't yet added Frank's suggested enabled/disabled flag in
> > struct kprobe. With the new design, this needs some thought.
>
>
> One possibility is to add the falg to the kprobe struct, and set it
> within disarm_kprobe.  For aggregate kprobes this would get set in the
> aggregate's substructure only.  The clients could get the flag in
> their own kprobe struct updated during the kprobe_unregister() call.

Or even better, check for the flag when you return to aggr_pre_handler
and set it in each of the kprobes in the list.

> Or disarm_kprobe could perform the same sort of downcasting check
> "old_p->pre_handler == aggr_pre_handler" as is in register_kprobe(), and
> traverse the individual kprobe structs directly.

The above method I think is better. That'll do it in arch independent
code.

> By the way, why is complete disarming (removal) deemed the appropriate
> response to reentrant probes?  What would go wrong if a nested kprobe
> call would be only ignored somehow, and go right to the
> single-stepping of its target instruction?  In other words, it would
> be nice if the consequence of reentrancy was not a total shutdown of
> such a kprobe, but a momentary suspension.

How/when will you reset the re-entry flag to revoke suspension and
start processing the probes as normal? How/when do you know it is safe
to do so?

> In either case, I think it's essential that the kprobe clients be told
> if they missed probes because of reentrancy (or other reasons).
> Without such an indication, one loses trust in systemtap results.

Agreed

> > [...]
> > 2.5.3	Fault handlers
> >
> > Fault handlers are called in sequence until one of them handles
> > the fault (returns non zero). Once a fault is handled, no other
> > handlers are called.
>
>
> I still don't think this is a very useful characteristic.  Can you
> imagine a usage scenario where it might be useful?
>
> > NOTE: 
> >
> > a. Fault handlers are meant not just to handle faults during
> >   the execution of the handlers, but also in cases when we fault
> >   while single-stepping out of line. This is the most common case
> >   with user-space probes [...]
>
>
> What can a custom kprobes fault handler do if a user-level instruction
> causes a fault?  How is it any more or less recoverable from the point
> of view of the user program, or the kernel, than if the kprobe was on
> a kernel instruction instead?

If you look at the notifier hooks that invoke the fault handler, they
are only at the entry of the page_fault and general protection paths,
and are used to shield the kernel from seeing this fault if caused by
the probes. Maybe I am not able to elucidate the issue well. Richard's 
post <http://sourceware.org/ml/systemtap/2005-q1/msg00050.html>
describes the case better.

> > b. In case we fault while executing a handler, only that kprobe's
> >   fault handler should be invoked. This design doesn't yet do
> >   that.
> > [...]
>
>
> The aggr_pre_handler / aggr_post_handler functions could find the
> appropriate current fault_handler within their internal loops, and put
> it in a place where aggr_fault_handler can find it

Again, this will work only if the fault was during the execution of the
handler and not post the single step emulation. But, as I had mentioned
on the earlier thread, this is doable. (In fact I had a patch to do this
wrt the earlier design). Something like the current_probe in the arch
kprobes files will work here.

Thanks,
Ananth