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]

Re: kprobe fault handling


Hi Frank,

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

yes, in situtations when fault_handler is executed, users can either
correct the faulty instruction and singlestep again or he can just
replace back the original instruction, disarm the probe and continue.
That will eventually trigger a kernel panic as if there was no probe
at that location.


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

Kprobes code does not handle the fault but just provides an opportunity
to correct by giving control to registered fault handler.

>What can I do from the fault handler to make sure that pre_handler
>execution is resumed, but the faulting instruction is *skipped*?

Skipping the instruction works in your testcase, but may not work
for other situations. Also to skip the instruction, you may need
to know the instruction length. In some architectures getting the
instruction length is easy like ppc64, but might not be easy in 
other architectures.

Also in such situations instead of just skipping the faulty instruction,
you can skip the whole routine, but that might trigger kernel panic
somewhere else.

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

Yes, it can done..by changing the instruction pointer to the singlestep
instruction and also setting the flags for single stepping. But if user fault 
handler would have corrected the faulted instruction, resuming with 
pre_handler() should also work. Am I missing something here????


Thanks
Prasanna
-- 

Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>


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