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

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

On Tue, Apr 12, 2005 at 09:33:48AM -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> 
> On Tue, Apr 12, 2005 at 12:23:32PM +0530, Suparna Bhattacharya wrote:
> > [...]
> > > >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. [...]
> 
> 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?
> 
> 
> > [...]
> > > 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.
> > [...]
> 
> Considering the big kprobe_lock, if the kprobes layer does not do away
> with this, the all kprobes clients that *can* tolerate execution of
> concurrent and reentrant handlers won't be able to enjoy it.  In other
> words, if the lower layer imposes a strict limitation on concurrency,
> then no higher layer can correct that in a practical way.
> 
> Can you conceive of a way of (a) leaving the kprobes low-level code
> and its existing clients unchanged, and (b) allowing a higher layer to
> support colocated probes, and (c) allowing a higher layer to enjoy
> concurrent probe execution?

Improving kprobes scalability would be an enhancement belonging in the
lower layer of course, but that is really independent of the multi-probe
feature. You just want the ability to process kprobe hits on different
processors concurrently.

> 
> If the answer is no, then something in the lower layer needs to
> change.  If this is not acceptable, then this throws into doubt
> systemtap's choice of breakpoint mechanism.
> 
> 
> > [...]  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 ? [...]
> 
> For example, from the the simple desire not to artificially limit
> independent concurrent systemtap sessions.  Because of the
> abstractions we intend to provide there, the script users may have
> little idea where the unwelcome colocation of probe points are coming
> from, and even less about how to reword their scripts to get around
> it.

OK, so you really are thinking of independent systemtap sessions, not
co-existence with other unrelated kprobe users.

As I mentioned above if the basic kprobes concurrency issue is solved
that should address your primary concern, right ? (Was something like a
per-probe reader-writer lock that you were thinking of, or am I
misinterpreting ?)

Regards
Suparna

> 
> 
> - FChE

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