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)


On Tue, Apr 12, 2005 at 04:21:36PM -0400, William Cohen wrote:
> 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.

OK - both of these are pretty reasonable requirements.

> 
> 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.

Yup, having it in a common place is a good idea, and that common
place should be inside the kernel, not in a separate module.
However, that common place doesn't *have* to be within the kprobes
low-level interface.

Most of the reasons for multiple probe handlers I've seen so far are
relevant for probes that are tracing and getting various system data.
Which is the generic tap sort of requirement - whether systemtap or
otherwise.

That however, isn't the only type of kprobe requirement. I'm not sure
I should even try to predict what kinds of things people may think of
(am sure to fail :))

I'd rather we keep the lowest level simple and truly low-level.

And I think the latest patches are almost there anyway.

> 
> 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.

I don't quite see why unregister will not know what kind of a probe
it registered. Systemtap would only use chainable variety of probes
anyway. What am I missing ?

Think of it like the wait queue functions -- usually most callers use
the higher level routines, but sometimes the lower-level ones are used
when a variation in semantics or lower-level of control is needed. That
allows an immense amount of flexibility, without having to push a lot
of flag interpretation and other logic into the core.

Regards
Suparna

> 
> -Will

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


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