Messages in this thread | | | Date | Tue, 01 Dec 2020 19:16:21 +0530 | From | "Naveen N. Rao" <> | Subject | Re: [RFC PATCH 01/14] ftrace: Fix updating FTRACE_FL_TRAMP |
| |
Steven Rostedt wrote: > On Thu, 26 Nov 2020 23:38:38 +0530 > "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote: > >> On powerpc, kprobe-direct.tc triggered FTRACE_WARN_ON() in >> ftrace_get_addr_new() followed by the below message: >> Bad trampoline accounting at: 000000004222522f (wake_up_process+0xc/0x20) (f0000001) >> >> The set of steps leading to this involved: >> - modprobe ftrace-direct-too >> - enable_probe >> - modprobe ftrace-direct >> - rmmod ftrace-direct <-- trigger >> >> The problem turned out to be that we were not updating flags in the >> ftrace record properly. From the above message about the trampoline >> accounting being bad, it can be seen that the ftrace record still has >> FTRACE_FL_TRAMP set though ftrace-direct module is going away. This >> happens because we are checking if any ftrace_ops has the >> FTRACE_FL_TRAMP flag set _before_ updating the filter hash. >> >> The fix for this is to look for any _other_ ftrace_ops that also needs >> FTRACE_FL_TRAMP. > > I'm applying this now and sending this for -rc and stable. > > The code worked on x86 because x86 has a way to make all users use > trampolines, so this was never an issue (everything has a trampoline). > I modified the kernel so that x86 would not create its own trampoline > (see the weak function arch_ftrace_update_trampoline(), and I was able > to reproduce the bug.
Good to know that you were able to reproduce this.
> > I'm adding: > > Cc: stable@vger.kernel.org > Fixes: a124692b698b0 ("ftrace: Enable trampoline when rec count returns back to one")
That looks good to me. Thanks for picking the two patches and for your review on the others!
- Naveen
| |