[RFC] Multiple kprobes at an address redux (take3)

[Vara Prasad]

Jim Keniston wrote:

>On Tue, 2005-04-12 at 06:33, Frank Ch. Eigler wrote:
>...
>  
>
>>>>>utility 1 inserts kprobe k1 with handler h1 at address A
>>>>>utility 2 wants to insert kprobe k2 with handler h2 at the same address A
>>>>>
>>>>>In this situation if we do _not_ fail user 2 and add handler h2 to the 
>>>>>existing kprobe, what might happen is that if at the hit of kprobe, the
>>>>>handler h1 can modify some data and things might not be as expected 
>>>>>by h2. [...]
>>>>>          
>>>>>
>>It seems to me that we're really stretching into the world of the
>>hypothetical to find some justification for the status quo.  Do there
>>exist any such probes that you know of?  Are they such that if an
>>immediately adjacent instruction was made the subject of the "utility
>>2" probe, that this hypothetical scenario would then work?
>>    
>>
>
>As Hien can verify, support for function-return probes (and in
>particular, registering and unregistering a return probe independently
>of the corresponding entry probe) is simplified considerably by the
>ability to register multiple kprobes at the same address.  I've
>encouraged Hien to investigate the possibility that the return-probe
>setup code could be just another pre_handler at the function's entry
>point.
>
>On the other hand, this is an example of a handler that modifies data
>(i.e., the return address) that another handler might need (e.g., to
>identify the caller).  The eventual implementation may require some
>special code to delay the replacement of the return address until all
>the pre_handlers have run.
>  
>
Well delaying the running of return probes handler only solves the 
problem of not affecting entry point handlers but if there is a probe at 
the middle of the function that probe will not find the caller correctly 
anyway.  The better method would be we need to provide a function that 
returns the address of the caller and this routine is smart enough to 
figure out where to get the callers address with or without return probes.

>Will this lead to the sort of "policy" infection that Suparna warned
>of?  I'd say no.  Return probes are a really useful feature that
>warrants a few extra lines here and there in the kprobes base, same as
>jprobes.  No need to create new, generalized call-chain semantics
>because of it.
>  
>
I am not sure how we can implement policy if there is no guarantee of 
the order of execution unless purpose of the policy is to implement such 
an order.

If we get into this policy area we might have to also worry about who 
gets priority safe mode or guru mode. Other issue related is, should we 
allow mixing of safe mode and guru mode in the system at the same time 
even if it is from different users.  I think this policy issue needs 
some more thought if we foresee a need for it.

>  
>
>>- FChE
>>
>>    
>>
>
>Jim
>
>
>  
>