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


Frank Ch. Eigler wrote:
Hi -


On Wed, Apr 06, 2005 at 10:48:21AM -0400, Ananth N Mavinakayanahalli wrote:



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

The current solution for fault handlers would only work if all the fault handlers are the same.


Would it be worthwhile to have a per cpu variable with a pointer to the current kprobe being executed? If fault occurs, the variable could be examined to determine which fault handler to run.

-Will


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