Re: [PATCH 6/9][RFC] kprobes: Allow probe on ftrace reserved text (but move it)

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

(2012/05/08 22:04), Steven Rostedt wrote:
> I guess the question is what's best long term. That's what I would like
> to do. If a flag is "good enough" for both now and long term, than
> that's fine with me. But if we find that it would be better to have a
> "real_addr" then we should do it now and bite the bullet with all archs.

Well, I was not sure that the moving probe address method was the
short-term solution. Maybe that was wrong.

>
> Otherwise, we'll have all the archs doing something special with the
> MOVE flag and that would cause even more pain to update it later.

Just a comment. If user find that the MOVE flag is set, then they can
 choose;
- reject the probing request which on the ftrace
- stores original IP on another variable and use that instead of
  kp->regs.
So, they don't need to adjust address for each arch. :)


> I also like the real addr because it helps with the optimize probes. We
> only need to search one location. This doesn't matter with this patch
> set, but with the code I have that uses ftrace hooks. One solution with
> that is to have the optimize code see that the probe was moved, (or its
> real addr was on a ftrace nop) and then just use the ftrace code on
  ^^^^^^^^^ would you mean addr? :)
> optimization instead of normal optimizations (replacing with a jump).

OK, I misunderstood. I thought that ftrace-optimization could replace
the moving probe address solution, but it couldn't.
For example, jprobe, which puts a probe on the entry of function and
change IP to special handler, can not be optimized even with ftrace.
Thus, we still need to move probe address to the next instruction.

So, I agree with you. We need real_addr solution for transparent
moving the probepoint.

> Note, the big difference with using ftrace optimization and normal
> kprobe jump optimization is that the ftrace one can be used on a preempt
> kernel. But this code is still under development. I want to get a
> solution for the current code (this patch set) now. It would be nice if
> it was ready for 3.5.

I doubt that we can really do this. If this is possible, I can make
jump optimization work with preemptive kernel.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com