This is the mail archive of the systemtap@sourceware.org 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]

kprobe fault handling


Hi -

I'm about to commit some translator code to set a fault_handler for
systemtap kprobes, as additional safety protection.  To test it, I've
tried the following little crashme script, which as you see
dereferences NULL.

  function ta () %{ * (volatile char *) 0 = 0; %}
  probe kernel.SOMEPLACE { ta () }

I'm getting far enough along with this that the fault handler is
indeed run, and a nice little message is sent via printk().  However,
what I'd like to do is signal that the probe handler should more or
less resume (and soon unwind and clean itself up with an error).

A "return 0" seems inappropriate, since this would trigger a kernel
panic.  A "return 1" seems not to work the way I expect, in that in my
tests, this gets us into an infinite loop, as if it was retrying the
NULL dereference every time.

What can I do from the fault handler to make sure that pre_handler
execution is resumed, but the faulting instruction is *skipped*?
Actually I don't even need the pre_handler to resume running, just the
kernel in general (single-stepping over the probed insn, and so on).
Is there a way to accomplish that?

- FChE


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