This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

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.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]