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

["Frank Ch. Eigler" <fche at redhat dot com>]

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.


> >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.


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


- FChE

Attachment: pgp00000.pgp
Description: PGP signature