Re: utrace-based uprobes

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Fri, 2007-03-16 at 11:50 -0700, Jim Keniston wrote:
> On Fri, 2007-03-16 at 17:28 +0100, Mark Wielaard wrote:
> > A suggestion would be to mark the code page as not executable
> > so any thread that accesses that code path gets trapped till the code
> > has been adjusted.
> 
> We settled on the quiesce-everybody approach a long time ago.  If we
> rejected your idea, I can't remember why.  Maybe a colleague will inform
> me.  Otherwise, it seems worth investigating.

Note that I have never seen any implementation of this, I just
remembered someone suggesting it. It might well be that it is highly
impractical in practise. But if nobody tried it before then this might
be an idea to add to the list to investigate.

> Returning to the wrong address.  For example, if A calls B, and you have
> uretprobes on both A and B, and B longjmps back into A, B's return
> address will be left atop that task's stack of return addresses.  So
> when A returns, it'll return using B's return address.
> 
> > (is it unsafe to add return
> > probes)?
> It's safe within the stated limitations.  In particular, it's fine if a
> process exits from within a uretprobed function.

OK, but it might be that a "wrongly" placed uretprobe actually changes
the behavior of the user program (not just the timing) because a
function could be returning to the wrong address because of it. If so,
then uretprobes would fail my definition of "safe" (compared to regular
uprobes). Unless I would have some mechanism to detect that a function
could have a non-regular return/jump behavior before deciding to place a
uretprobe.

Cheers,

Mark