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

[Jim Keniston]

On Tue, 2005-04-12 at 06:33, Frank Ch. Eigler wrote:
...
> > > >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?

As Hien can verify, support for function-return probes (and in
particular, registering and unregistering a return probe independently
of the corresponding entry probe) is simplified considerably by the
ability to register multiple kprobes at the same address.  I've
encouraged Hien to investigate the possibility that the return-probe
setup code could be just another pre_handler at the function's entry
point.

On the other hand, this is an example of a handler that modifies data
(i.e., the return address) that another handler might need (e.g., to
identify the caller).  The eventual implementation may require some
special code to delay the replacement of the return address until all
the pre_handlers have run.

Will this lead to the sort of "policy" infection that Suparna warned
of?  I'd say no.  Return probes are a really useful feature that
warrants a few extra lines here and there in the kprobes base, same as
jprobes.  No need to create new, generalized call-chain semantics
because of it.

> 
> - FChE
> 

Jim