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