Messages in this thread | | | Date | Mon, 2 Nov 2009 21:22:04 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 0/3][RFC] tracing/kprobes: prevent jprobes from crashing function graph tracer |
| |
On Mon, Nov 02, 2009 at 10:02:23AM -0500, Masami Hiramatsu wrote: > Frederic Weisbecker wrote: >> I'm not sure I've well understood how is performed the call to the jprobe >> handler. >> But if I understand well we have: >> >> func() { >> int3() { >> jprobe_handler() { >> (-) >> set ip after iret to user_handler() >> } >> } >> user_handler() { >> jprobe_return() { >> (+) >> int3() { >> set ip after iret to func+...() >> } >> | >> | >> | >> <-------------- >> (execute the rest of func()) >> } >> >> If we replace (-) with pause_graph_tracing() and (+) with >> unpause_graph_tracing(), this should do the trick...I hope. > > I'm not so sure about pause_graph_tracing(), however, it seems that > int3() and jprobe_handler() already pushed on the stack of the > func graph tracer at (-). If it's true, where are those entries > popped up? >
pause_graph_tracing() will disable the tracing for the current task but it won't disable the address pop from stack.
If the above jprobe scheme is right, the scenario will be:
func() { /* push func ret */ int3() { /* push do_trap ret */ jprobe_handler() { /* push jprobe_handler ret */ pause_graph_tracing(); set ip after iret to user_handler() } /* pop jprobe_handler ret */ } /* pop do_trap ret */ user_handler() { jprobe_return() { unpause_graph_tracing() int3() { /* push do_trap ret */ set ip after iret to func+...() } /* pop do_trap ret */ | | | <-------------- (execute the rest of func()) } /* pop func ret */
Hmm?
| |