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

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

Frank Ch. Eigler wrote:
> Hi -
>
>
> On Fri, Apr 01, 2005 at 09:34:28AM -0500, Ananth N Mavinakayanahalli wrote:
>
> > Here is a design to support "Mulitple handler sets per address". I have 
> > also put in the i386 implementation based on this design.
>
>
> Thank you.
>
>
>
> > 2.4.2.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.
>
>
> This sounds wrong.  If at all possible, the code should arrange to
> call only the single fault handler that corresponds to the current
> specific kprobe being handled.
>
> Keep in mind that one use for this feature is for running several
> independent systemtap sessions at the same time.  They should remain
> as isolated from and ignorant of each other as possible.  In
> particular, one should not be told that the other has happened to
> cause a fault.  Similarly, one client should not be able to prevent
> another client from getting its probe handler called, by returning a
> "success" indication of its own.

Good point. One way of tracking which handler caused the fault
would be to have a struct kprobe *current_handler.

Any suggestions?

> > [...]
> > - Multiple handlers cannot be registered at a location that already
> >  has a jprobe registered. In other words, to register a jprobe,
> >  no other handlers must be registered at that address and 
> >  vice-versa.
>
>
> Could you be more specific about why this limitation needs to exist?
> To what extent does the execution of a jprobe handler mess up the
> possibility of also running a kprobe handler at the same spot?
>  

The design of jprobes is such that you take two traps before single
stepping - you don't single-step until after the jprobe->entry
routine has caused a trap due to a jprobe_return and the
break_handler has reset the stacks to their original condition.

Remember, we have to return from the exception so that the
jprobe->entry routine gets executed. We modify regs->eip to point
to jprobe->entry and this change isn't what other (kprobe) handlers
at the address are expecting.

A simple/straight forward method to allow such a functionality to
co-exist along with other kprobe(_only) handlers at the same
address did not occur to me. But, feel free to prove me wrong.
The lesser the restriction, the better :)

> > - We currently silently disarm the kprobe if we are recursing 
> >  and ignore it. Do we have to change that?
>
>
> Reentrancy control is likely to remain essential.  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.

My thought was more towards scavenging probes that were silently
disabled, now that struct aggr_kp is alloced and freed by the kprobe
infrastructure and not the user. Come to think of it, this shouldn't
be a issue as the aggr_kp gets freed when all handlers are unregistered.

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.

Thanks,
Ananth