On Mon, May 6, 2019 at 11:57 AM Steven Rostedt rostedt@goodmis.org wrote:
You should have waited another week to open that merge window ;-)
Hmm. I'm looking at it while the test builds happen, and since I don't see what's wrong in the low-level entry code, I'm looking at the ftrace code instead.
What's going on here?
*pregs = int3_emulate_call(regs, (unsigned long)ftrace_regs_caller);
that line makes no sense. Why would we emulate a call to ftrace_regs_caller()? That function sets up a pt_regs, and then calls ftrace_stub().
But we *have* pt_regs here already with the right values. Why isn't this just a direct call to ftrace_stub() from within the int3 handler?
And the thing is, calling ftrace_regs_caller() looks wrong, because that's not what happens for *real* mcount handling, which uses that "create_trampoline()" to create the thing we're supposed to really use?
Anyway, I simply don't understand the code, so I'm confused. But why is the int3 emulation creating a call that doesn't seem to match what the instruction that we're actually rewriting is supposed to do?
IOW, it looks to me like ftrace_int3_handler() is actually emulating something different than what ftrace_modify_code() is actually modifying the code to do!
Since the only caller of ftrace_modify_code() is update_ftrace_func(), why is that function not just saving the target and we'd emulate the call to that? Using anything else looks crazy?
But as mentioned, I just don't understand the ftrace logic. It looks insane to me, and much more likely to be buggy than the very simple entry code.
Linus