lkml.org 
[lkml]   [2009]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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?



\
 
 \ /
  Last update: 2009-11-02 21:25    [W:0.046 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site