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

[Suparna Bhattacharya <suparna at in dot ibm dot com>]

On Mon, Apr 11, 2005 at 10:59:10PM -0700, Vara Prasad wrote:
> Maneesh Soni wrote:
> 
> >On Tue, Apr 12, 2005 at 09:26:50AM +0530, Suparna Bhattacharya wrote:
> > 
> >
> >>It would be nice to summarize all the requirements upfront, before
> >>moving on to the design.
> >>
> >>   
> >>
> >
> >I had the impression that systemTap needs that register_kprobe() should 
> >never fail with -EEXIST. That means, if there is a kprobe inserted by some 
> >other utility at the same location where systemTap wants to insert, the 
> >kprobe
> >mechanism should still go ahead and add handlers to the existing kprobe.
> > 
> >
> That is right, we should allow multiple handlers at any given probe point.
> 
> >Thanks to Suparna, I see there could be a problem in this which might 
> >occur due to this non-exclusiveness of kprobes. Consider the following 
> >scenario,
> >
> >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. The result 
> >could be the incorrect information being provided by utility 2.
> >
> When we have multiple handlers we are not guaranteeing the order of 
> execution of probes hence probe handlers should not assume any order. 
> Handlers should  have the logic to verify the data of their interest 
> before using,  if data is not appropriate they should handle that 
> gracefully and exit.
> 
> >
> >
> >I understand that systemTap needs multiple handler probes, but still there 
> >should be some exclusiveness among the kprobes inserted by different 
> >utilities.
> >One utility can synchronize its own multiple handlers for the same probe 
> >but
> >with other utilities.
> > 
> >
> I think synchronization should be left to the users of the probes rather 
> than trying to complicate the interface with exclusive probes and non 
> exclusive probes. 

Indeed. That is exactly the point -- we can impose the requirement of
verification on systemtap probes or multihandler probes in general,
but changing all kprobes users to do this may not be appropriate.
Simply keeping the same name of the interface and changing its semantics is
potentially problematic.

kprobes is a simple low level interface - the only expectation on
kprobes handlers today is ability to execute in interrupt context
and not recurse into itself. Other than that, a handler is a kernel
function - which can do whatever it wants ... it would be rather hard
if not impossible to verify everything.

So, I can't see a way to make unrelated sets of users of probes
to synchronize themselves :(

This is why having the higher level kprobe call chain (for want of a better
name), abstracted on top of kprobes made sense to me. 

Could you explain the need for systemtap to takeover or insert additional
handlers to existing kprobes in the system (potentially installed by
other utilities or even by a kernel programmer for quick experimentation)
a little more clearly ? Where did that requirement originate ? (I'm sorry
I haven't really been following the design discussions on system tap)

Regards
Suparna

> 
> >Probably now we need to modify the design having this problem in mind.
> >
> >Thanks
> >Maneesh
> >
> > 
> >
> 
> 

-- 
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India