Re: ftrace bug

[Arend Van Spriel]

On March 8, 2022 5:03:00 PM Alexander Sverdlin 
<alexander.sverdlin@xxxxxxxxx> 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@xxxxxxxxx>
> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature