[RFC] Design + prototype: Multiple handler sets per probe address

[Ananth N Mavinakayanahalli]

Frank Ch. Eigler wrote:
> Hi -
> 
> 
> On Fri, Apr 01, 2005 at 11:15:58AM -0500, Ananth N Mavinakayanahalli wrote:
> 
>>>[...]
>>>Keep in mind that one use for this feature is for running several
>>>independent systemtap sessions at the same time.  [...]
>>
>>Good point. One way of tracking which handler caused the fault
>>would be to have a struct kprobe *current_handler. [...]
> 
> 
> Yes, except that global variables are a pain from the point of view of
> proper support for concurrent kprobe execution on an SMP.  Maybe it's
> as simple as keeping per-cpu "global" state only.

Well, thinking about this a bit more, its not as simple as it appears
to be. What if we fault on the instruction being single-stepped (most
common case) rather than while executing the handler? In that case,
which handler is responsible to handle the fault?

> 
>>>Could you be more specific about why this limitation needs to exist?
>>>[...]
>>
>>The design of jprobes is such [...]
> 
> 
> Thanks for the explanation.  I don't quite grok it yet, but that's
> okay, but it sounds complex enough to force us to accept an
> incompatibility between jprobes and kprobes.

:-) Jprobes took me some time to grasp too, when I was implementing
it for ppc64. Suparna was kind enough to explain it to me (atleast two
times, I must add) so I could come up with a working ppc64 patch.
Thanks Suparna!

> 
>>>[...]  It would be nice if some counter was kept of the number of
>>>times that a probe was skipped due to reasons like this, so that
>>>ultimately a user become aware that something went wrong.
>>
>>[...]
>>I don't get the a counter idea though. When we recognize recursion
>>the first time, the trap instruction at the offending address is
>>removed and so we don't register subsequent hits at all.
> 
> 
> Even if that offending reentrant trap is removed permanently (rather
> than temporarily), the inserter of that trap should be told that this
> has happened.  After all, this is an error indication, like being
> out-of-memory.  Maybe the kprobes struct itself should contain a
> counter or flag that some events were missed because of reentrancy.
> The caller can check on that flag periodically to decide whether to
> abort (say) the systemtap run.

Hmm, how about struct aggr_kp having an "active" field, which is
default active until a call to disarm_kprobe() resets it. We can
then provide

int kprobe_active(kprobe_opcode_t *addr)

using which the inserter can determine whether or not the kprobe at
the address is active.


Thanks,
Ananth