RE: [KPROBE][RFC] Tweak to the function return probe design

["Lynch, Rusty" <rusty dot lynch at intel dot com>]

From: Hien Nguyen [mailto:hien@us.ibm.com]
>Hi Rusty,
>
>This looks good. See my comments below
>
>Rusty Lynch wrote:
>

<snip>
>>* Instead of storing the stack address in the return probe instance,
the
>>  task pointer is stored.  This gives us all we need in order to:
>>    - find the correct return probe instance when we enter the
trampoline
>>      (even if we are recursing)
>>
>>
>What about the case user probing different functions in the same task?
>As I and Jim discussed about this, it probably works since you put the
>RI the hlist and get it out in the same order. But in the case user
>probing several function-returns but the one in the middle never
return,
>your code would fire the wrong handler.

How could I not return from a function but still return from a previous
call (i.e. have the parent function return with the child function left
in limbo)?  I guess you could directly mess with the instruction
pointer, but wouldn't that mess up the stack address anyway?

>
>I thought I would be safer for us to have  the "statck_addr" field in
>kretprobe_instance structure for sanity check. It would not be much
>code  to add, just one line to populate the stack_addr in the
>arch_prepare_kretprobe() and may be a couple line to do the check in
the
>handler.

The concept of a stack address to uniquely identify a specific call
instance inside a task is architecture dependant.  I would really like
to resolve if it is possible for a function with the same task living
on.

<snip>
>>@@ -155,8 +148,8 @@ struct kretprobe_instance {
>> 	struct hlist_node uflist; /* either on free list or used list */
>> 	struct hlist_node hlist;
>> 	struct kretprobe *rp;
>>-	void *ret_addr;
>>-	void *stack_addr;
>>+	unsigned long *ret_addr;
>>
>>
>As Ananth suggested to me before, you could use
>
>        kprobe_opcode_t * ret_addr;
>

Yea, I like that better.

    --rusty