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

[Maneesh Soni]

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.

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. 

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.

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

Thanks
Maneesh

-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044990