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

[William Cohen <wcohen at redhat dot com>]

Suparna Bhattacharya wrote:
> On Mon, Apr 11, 2005 at 10:59:10PM -0700, Vara Prasad wrote:
...

> > Maneesh Soni wrote:
> > 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.

How many kprobes have been written that is going to present a 
significant problem?

> 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

There are two situations where systemtap could insert multiple probes at 
a single address:

1) Composing two systemtap pieces of instrumentation in an experiment. 
One example would be entry and exit probes. The proposed exit probes 
implement actually instruments the function entry. Thus, there would be 
two probes on the function entry.

2) Multiple experiments running concurrently. A person starts up a 
systemtap script and then starts a second indepedent script to get some 
other data while the first is running. The two scripts could instrument 
the same address. Trying to determine whether this is going to happen 
statically is not feasiable.

Putting the code to handle multiple probes in the systemtap module is 
the wrong place. The code to handle multiple probes at an address should 
be factored out and put in the kprobes.

Having two different interfaces to manage kprobes seems like it would be 
troublesome. Need to call different register and unregister based on 
whether the kprobe was exclusive or not. If there is a need for that 
information might as well store it in the kprobe structure.

-Will