Re: [Fwd: Re: [PATCH] Return probe]

[Prasanna S Panchamukhi <prasanna at in dot ibm dot com>]

Hi,

> Yes this does add few instructions to do the cleanup but i am not sure 
> if this is really a performance overhead.
> 

Jim/Hien, can you get some performance numbers and details about your
performance measurements.

> >Also this method could not use multiple handlers feature 
> >in a cleaner way. 
> Can you give more details of what you mean by cleaner way?
> 

Please see my next email.

> 
> >
> We can probably track the current task but to me this has two 
> disadvantages one is we will get way many traps then function returns. 

This might happen, only for the duration from function entry to the function
exit , since the probe @return address will be removed after the
function returns. If the function takes lots of time before it returns
this window will remain.

> The second the task of keeping track of which traps are real and which 
> are false makes it difficult to associate exit calls with corresponding 
> entry calls hence prone to bugs.
> 

You can use the current task struct to figure that out. 


> Just to summarize your main concerns i hear about this approach are
> 1) We are adding little bit of additional cleanup code in the exit and 
> exec paths
> 2) If there is a stack corruption we have no clue of when the function 
> returns
> 

Just trying to figure out where this approach might fail. There are lots of
references to __builtin_return_address() in the kernel. If a kretprobe is 
placed on some routine() and that routine calls __builtin_return_address(), then
__builtin_return_address() will return incorrect value, since kretprobe modifies
the retaddress stored on the stack. Not sure if this limitation is acceptable ?

Thanks
Prasanna

-- 

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