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


William Cohen wrote:
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.

As of now, ie., with a global kprobe spinlock, something like the arch code's current_kprobe will suffice. When we tackle the kprobe scalability issue, we can decide which mechanism (per-cpu) or otherwise is necessary, right?

Thanks,
Ananth


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