On Mon, May 6, 2019 at 1:29 PM Steven Rostedt rostedt@goodmis.org wrote:
Because that call to ftrace_stub is also dynamic.
You're missing the point.
We are rewriting a single "cal" instruction to point to something.
The "int3" emulation should call THE SAME THING.
Right now it doesn't.
Part of the code will change it to call the function needed directly.
struct ftrace_ops my_ops { .func = my_handler };
register_ftrace_function(&my_ops);Will change "call ftrace_stub" into "call my_handler"
But that's not what you're actually *doing*.
Instead, you're now _emulating_ calling ftrace_regs_caller, which will call that ftrace_stub, which in turn will try to update the call site.
But that's insane. It's insane because
- it's not even what your call rewriting is doing Why aren't you just doing the emulation using the *SAME* target that you're rewriting the actual call instruction with?
- even if ftrace_regs_caller ends up being that same function, you'd be better off just passing the "struct pt_regs" that you *ALREADY HAVE* directly to ftrace_stub in the int3 handler, rather than create *another* pt_regs stack
See? In that second case, why don't you just use "int3_emulate_call()" to do the reguired 'struct pt_regs' updates, and then call ftrace_stub() *with* that fixed-up pt_regs thing?
In other words, I think you should always do "int3_emulate_call()" with the *exact* same address that the instruction you are rewriting is using. There's no "three different cases". The only possible cases are "am I rewriting a jump" or "am I rewriting a call".
There is no "am I rewriting a call to one address, and then emulating it with a call to another address" case that makes sense.
What *can* make sense is "Oh, I'm emulating a call, but I know that call will be rewritten, so let me emulate the call and then short-circuit the emulation immediately".
But that is not what the ftrace code is doing. The ftrace code is doing something odd and insane.
And no, your "explanation" makes no sense. Because it doesn't actually touch on the fundamental insanity.
Linus