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

[Ananth N Mavinakayanahalli]

William Cohen wrote:
> 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.

As of now, ie., with a global kprobe spinlock, something like the arch
code's current_kprobe will suffice. When we tackle the kprobe
scalability issue, we can decide which mechanism (per-cpu) or otherwise
is necessary, right?

Thanks,
Ananth