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

[Ananth N Mavinakayanahalli]

Suparna Bhattacharya wrote:

Hello Suparna,

> It would be nice to summarize all the requirements upfront, before
> moving on to the design.
> 
> One observation I have is that a register_single_kprobe equivalent 
> is still useful for those who might be setting up a kprobe for debugging
> or fault injection purposes --  or rather maybe something like
> register_exclusive_kprobe, because one might not want to be surprised by
> having multiple handlers clicking away in such a situation.

Yes, this is something we have to be congnizant of. So, here is what I
propose:

We have a "coexist" field in struct kprobe which is default 0. This
means that the kprobe cannot tolerate other kprobes at the same address.
A non zero value would indicate the kprobe can be one of many at the
address.

Then:

- In case we get a registration request for a location that already has
a kprobe with "coexist" = 0, we fail the new one with -EUSERS (or any
other appropriate error code).
- In case we already have a kprobe at the location with "coexist" = 1
and the new request is with "coexist" = 0, we fail that too. (basically
a sort of first-come-first-serve algorithm).
- In case we have a kprobe with "coexist" = 1 and the new one is also
with "coexist" = 1, then we go ahead and register the probe.

I think with this solution, we can safely say that people who would
not want to be surprised by multiple handlers can still continue using
kprobes as they currently do. Only those who are aware of and would not
mind multiple probes would then set the "coexist" flag to a non-zero
value. I also think that this will then make the requirement of a new
set of interfaces moot.

Attached is a patch that applies on top of the one I posted yesterday
and provides this functionality.

> That brings me to the other question -- typically whenever we have
> a call-chain of this sort, policy isn't very far behind ... quite
> soon we find ourselves wanting priorities between handlers or
> to decide whether to continue calling rest of the handlers or
> short circuit through depending on the result of an earlier handler
> etc. Sort of like notifiers ...

If I understand correctly, the (current) users that require multiple
kprobes at an address are not particular about the order of invocation
of the handlers. IMHO, we should not be supporting priorities wrt
handlers when multiple kprobes are registered.

As for short-circuiting handlers, that is a tricky one. We wouldn't want
to do that until there is a safe way to co-ordinate the pre and post
handler runs, ie., in case we have 3 kprobes at an address, we wouldn't
want all three post_handlers to run if the first pre_handler would have
returned a code that would've prevented other pre_handlers from running.

> Perhaps that isn't something that would be very relevant for
> probes which are just used for tracing purposes by various subsystems,
> which is where I guess the multiple handler requirement arose.
> 
> But in the more general case, is the design flexible enough to
> allow policy to be built _over_ this infrastructure (again of course
> without cluttering the core kprobes logic) ?
> 
> Nomenclature wise - both aggr_probe and multi-probe are names that
> sound more like a set of different probes, not multiple handlers
> for the same probe as is really intended. Ideas for better names ?

"manager kprobe"? Don't know what would be a good name, really :)

Thanks,
Ananth
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: safe-new-approach-12apr-working.patch
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050412/c2ccaa5a/attachment.ksh>