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

[Frank Ch. Eigler]

Hi -


On Fri, Apr 01, 2005 at 05:15:16PM -0500, Ananth N Mavinakayanahalli wrote:

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

Is this really a common case?  If the instruction "under" the kprobe
faults, doesn't that mean that the whole system is suddenly suspect?
After all, how would the kernel recover from some breakpoint-marked
instruction running into fault?

I thought the fault handler was there exclusively to catch problems
caused by a misbehaving pre_ or post_ handler.


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

It might be simpler to think about this from the point of view of each
kprobes struct.  When such a kprobe is killed due to reentrancy, walk
the aggr_kp's kprobe list, and set a "cancelled" flag in each one.
Since these structs are supposed to be allocated statically (with
respect to the probing session), the caller can just look at the
result right there.  No new function call is needed.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050401/21cf0d7e/attachment.sig>