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

[William Cohen]

Frank Ch. Eigler wrote:
> Hi -
> 
> 
> On Wed, Apr 06, 2005 at 10:48:21AM -0400, Ananth N Mavinakayanahalli wrote:
> 

>>[...]
>>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?
> 
> 
>>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.

The current solution for fault handlers would only work if all the fault 
handlers are the same.

Would it be worthwhile to have a per cpu variable with a pointer to the 
current kprobe being executed? If fault occurs, the variable could be 
examined to determine which fault handler to run.

-Will