Re: [Fwd: Re: [PATCH] Return probe]

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Tue, 2005-04-19 at 09:29, Richard J Moore wrote:
> 
> 
> Do you take into account the problems I documented in my technical
> disclosure on implementing return points?

I don't believe I've seen your disclosure, but yes, we've taken these
problems into account.

> These are:
> 
> 1) What happens if the return address is modified by the called program
> (legitimately or otherwise)?

Assuming it's modified after the entry probe has been hit and processed,
the modified return address will be used.  The trampoline won't be hit,
the return handler won't be run, and we'll leak a kretprobe_instance
object.  If we eventually leak all that kretprobe's kretprobe_instance
objects, the return handler for that kretprobe won't run any more, and
the kretprobe's nmissed counter will grow accordingly. Nothing else will
be affected.

> 2) What happens if a multi-level function return takes place? This is quite
> possible with optimization and some finite-state-machine implementations.

If the number of calls doesn't match the number of returns, it's a
problem.  We have added code to handle the possibility of probed
functions being active when the stack is discarded at exec or exit time.
We restore the original RAs to the stack (in case they're needed) and
recycle the unused kretprobe_instance objects.  I don't know of any
other situation where # calls != # returns.

> 3) What happens in the function call is register based (PPC, zSeries etc,
> optimized IA32 etc...)

As previously described (2/18/05, 3/11/05), this should work for ppc64,
or any architecture where the RA is in a predictable register or memory
location when you hit the first instruction of the function.  I don't
know the zSeries architecture well enough to comment.  If there are
optimizations on other architectures such that we can't currently
predict where the return address is, we'll have to get smarter or ask
the user for help.

The one problem I see for ppc64 is that of restoring the original RAs to
the stack (unless we can reliably predict where in the stack frames
they're saved).  This would be a problem only when probing functions
that (possibly indirectly) call flush_thread() or exit_thread() and
actually return.
> 
> - -
> Richard J Moore
> IBM Advanced Linux Response Team - Linux Technology Centre
> MOBEX: 264807; Mobile (+44) (0)7739-875237
> Office: (+44) (0)1962-817072

I believe that all these limitations can be documented along with other
kprobes limitations, and don't seriously affect the usefulness of the
feature.

Jim