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 kprobes at an address - take 2


Hi -


On Wed, Apr 06, 2005 at 10:48:21AM -0400, Ananth N Mavinakayanahalli wrote:
> [...]
> 1. I haven't yet added Frank's suggested enabled/disabled flag in
> struct kprobe. With the new design, this needs some thought.

One possibility is to add the falg to the kprobe struct, and set it
within disarm_kprobe.  For aggregate kprobes this would get set in the
aggregate's substructure only.  The clients could get the flag in
their own kprobe struct updated during the kprobe_unregister() call.

Or disarm_kprobe could perform the same sort of downcasting check
"old_p->pre_handler == aggr_pre_handler" as is in register_kprobe(), and
traverse the individual kprobe structs directly.

By the way, why is complete disarming (removal) deemed the appropriate
response to reentrant probes?  What would go wrong if a nested kprobe
call would be only ignored somehow, and go right to the
single-stepping of its target instruction?  In other words, it would
be nice if the consequence of reentrancy was not a total shutdown of
such a kprobe, but a momentary suspension.

In either case, I think it's essential that the kprobe clients be told
if they missed probes because of reentrancy (or other reasons).
Without such an indication, one loses trust in systemtap results.


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


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


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