[RFC] Design + prototype: Multiple kprobes at an address - take 2

[Ananth N Mavinakayanahalli]

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