This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]