Messages in this thread | | | From | Arend Van Spriel <> | Date | Tue, 08 Mar 2022 18:29:08 +0100 | Subject | Re: ftrace bug |
| |
On March 8, 2022 5:03:00 PM Alexander Sverdlin <alexander.sverdlin@nokia.com> wrote:
> Hi Arend! > > On 08/03/2022 16:20, Steven Rostedt wrote: >>>> I wanted to use FTRACE on an ARM platform and I hit the following >>>> warning which results in ftrace bug. This happens upon loading a module. >>>> Looking up the warning I suspect the branch target is too far off. The >>>> module is quite large and therefor not loaded in the modules section. Is >>>> there a way to exclude a module. In ftrace_module_init I see a check for >>>> !mod->num_ftrace_callsites. Is there a way to avoid creating ftrace >>>> callsites in a module? >>> Are you sure it's the size. Just want to make sure that's the reason before >>> going with different solutions. >> Interpreting the warning statement in insn.c and given the fact that the >> module is loaded at 0xe3xxxxxx instead of kernel module space at >> 0xbfxxxxxx I made this assumption, but .... >> >>>> Regards, >>>> Arend >>>> >>>> ------------[ cut here ]------------ >>>> >>>> WARNING: CPU: 2 PID: 1525 at arch/arm/kernel/insn.c:47 >>>> __arm_gen_branch+0x70/0x78 >>>> >>>> CPU: 2 PID: 1525 Comm: insmod Tainted: P 4.19.183 #2 > > This problem is addressed by:
Cool. Thanks for the info.
> commit 8113e622926ef6590771ede0f7f64821e1751b67 > Author: Alex Sverdlin <alexander.sverdlin@nokia.com> > Date: Mon Sep 27 14:02:45 2021 -0700 > > ARM: 9079/1: ftrace: Add MODULE_PLTS support > > commit 79f32b221b18c15a98507b101ef4beb52444cc6f upstream > > Teach ftrace_make_call() and ftrace_make_nop() about PLTs. > Teach PLT code about FTRACE and all its callbacks. > Otherwise the following might happen: > > ------------[ cut here ]------------ > WARNING: CPU: 14 PID: 2265 at .../arch/arm/kernel/insn.c:14 > __arm_gen_branch+0x83/0x8c() > ... > Hardware name: LSI Axxia AXM55XX > [<c0314a49>] (unwind_backtrace) from [<c03115e9>] (show_stack+0x11/0x14) > [<c03115e9>] (show_stack) from [<c0519f51>] (dump_stack+0x81/0xa8) > [<c0519f51>] (dump_stack) from [<c032185d>] (warn_slowpath_common+0x69/0x90) > [<c032185d>] (warn_slowpath_common) from [<c03218f3>] > (warn_slowpath_null+0x17/0x1c) > [<c03218f3>] (warn_slowpath_null) from [<c03143cf>] > (__arm_gen_branch+0x83/0x8c) > [<c03143cf>] (__arm_gen_branch) from [<c0314337>] (ftrace_make_nop+0xf/0x24) > [<c0314337>] (ftrace_make_nop) from [<c038ebcb>] > (ftrace_process_locs+0x27b/0x3e8) > [<c038ebcb>] (ftrace_process_locs) from [<c0378d79>] > (load_module+0x11e9/0x1a44) > [<c0378d79>] (load_module) from [<c037974d>] (SyS_finit_module+0x59/0x84) > [<c037974d>] (SyS_finit_module) from [<c030e981>] (ret_fast_syscall+0x1/0x18) > ---[ end trace e1b64ced7a89adcc ]--- > ------------[ cut here ]------------ > > And if you wanna stick with 4.19.y, it's included starting from v4.19.209.
Will see if our router kernel team wants to move. At least I can try my own experiment with this.
Regards, Arend
[unhandled content-type:application/pkcs7-signature] | |