| Message ID | 20210330114035.18575-1-alexander.sverdlin@nokia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM: Implement MODULE_PLT support in FTRACE | expand |
On 3/30/21 4:40 AM, Alexander A Sverdlin wrote: > From: Alexander Sverdlin <alexander.sverdlin@nokia.com> > > FTRACE's function tracer currently doesn't always work on ARM with > MODULE_PLT option enabled. If the module is loaded too far, FTRACE's > code modifier cannot cope with introduced veneers and turns the > function tracer off globally. > > ARM64 already has a solution for the problem, refer to the following > patches: > > arm64: ftrace: emit ftrace-mod.o contents through code > arm64: module-plts: factor out PLT generation code for ftrace > arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels > arm64: ftrace: fix building without CONFIG_MODULES > arm64: ftrace: add support for far branches to dynamic ftrace > arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() > > But the presented ARM variant has just a half of the footprint in terms of > the changed LoCs. It also retains the code validation-before-modification > instead of switching it off. > > Changelog: > v8: > * Add warn suppress parameter to arm_gen_branch_link() > v7: > * rebased > v6: > * rebased > v5: > * BUILD_BUG_ON() ensures fixed_plts[] always fits one PLT block > * use "for" loop instead of "while" > * scripts/recordmcount is filtering reloc types > v4: > * Fixed build without CONFIG_FUNCTION_TRACER > * Reorganized pre-allocated PLTs handling in get_module_plt(), > now compiler eliminates the whole FTRACE-related handling code > if ARRAY_SIZE(fixed_plts) == 0 > v3: > * Only extend struct dyn_arch_ftrace when ARM_MODULE_PLTS is enabled > v2: > * As suggested by Steven Rostedt, refrain from tree-wide API modification, > save module pointer in struct dyn_arch_ftrace instead (PowerPC way) > > Alexander Sverdlin (3): > ARM: PLT: Move struct plt_entries definition to header > ARM: Add warn suppress parameter to arm_gen_branch_link() > ARM: ftrace: Add MODULE_PLTS support Tested-by: Florian Fainelli <f.fainelli@gmail.com> Thanks a lot!
On 3/30/21 4:40 AM, Alexander A Sverdlin wrote: > From: Alexander Sverdlin <alexander.sverdlin@nokia.com> > > FTRACE's function tracer currently doesn't always work on ARM with > MODULE_PLT option enabled. If the module is loaded too far, FTRACE's > code modifier cannot cope with introduced veneers and turns the > function tracer off globally. > > ARM64 already has a solution for the problem, refer to the following > patches: > > arm64: ftrace: emit ftrace-mod.o contents through code > arm64: module-plts: factor out PLT generation code for ftrace > arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels > arm64: ftrace: fix building without CONFIG_MODULES > arm64: ftrace: add support for far branches to dynamic ftrace > arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() > > But the presented ARM variant has just a half of the footprint in terms of > the changed LoCs. It also retains the code validation-before-modification > instead of switching it off. > > Changelog: > v8: > * Add warn suppress parameter to arm_gen_branch_link() > v7: > * rebased > v6: > * rebased > v5: > * BUILD_BUG_ON() ensures fixed_plts[] always fits one PLT block > * use "for" loop instead of "while" > * scripts/recordmcount is filtering reloc types > v4: > * Fixed build without CONFIG_FUNCTION_TRACER > * Reorganized pre-allocated PLTs handling in get_module_plt(), > now compiler eliminates the whole FTRACE-related handling code > if ARRAY_SIZE(fixed_plts) == 0 > v3: > * Only extend struct dyn_arch_ftrace when ARM_MODULE_PLTS is enabled > v2: > * As suggested by Steven Rostedt, refrain from tree-wide API modification, > save module pointer in struct dyn_arch_ftrace instead (PowerPC way) FWIW, ftracetest did not pick up new failures (nor were new tests fixed) with this patch series.
Adding Linus Walleij back to CC On 03/30/21 13:40, Alexander A Sverdlin wrote: > From: Alexander Sverdlin <alexander.sverdlin@nokia.com> > > FTRACE's function tracer currently doesn't always work on ARM with > MODULE_PLT option enabled. If the module is loaded too far, FTRACE's > code modifier cannot cope with introduced veneers and turns the > function tracer off globally. > > ARM64 already has a solution for the problem, refer to the following > patches: > > arm64: ftrace: emit ftrace-mod.o contents through code > arm64: module-plts: factor out PLT generation code for ftrace > arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels > arm64: ftrace: fix building without CONFIG_MODULES > arm64: ftrace: add support for far branches to dynamic ftrace > arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() > > But the presented ARM variant has just a half of the footprint in terms of > the changed LoCs. It also retains the code validation-before-modification > instead of switching it off. > > Changelog: > v8: > * Add warn suppress parameter to arm_gen_branch_link() I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't work out for you? I struggle to see how this is better and why it was hard to incorporate my suggestion. For example - old = ftrace_call_replace(ip, adjust_address(rec, addr)); +#ifdef CONFIG_ARM_MODULE_PLTS + /* mod is only supplied during module loading */ + if (!mod) + mod = rec->arch.mod; + else + rec->arch.mod = mod; +#endif + + old = ftrace_call_replace(ip, aaddr, + !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod); +#ifdef CONFIG_ARM_MODULE_PLTS + if (!old && mod) { + aaddr = get_module_plt(mod, ip, aaddr); + old = ftrace_call_replace(ip, aaddr, true); + } +#endif + There's an ifdef, followed by a code that embeds !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/ And there was no need to make the new warn arg visible all the way to ftrace_call_repalce() and all of its users. FWIW Tested-by: Qais Yousef <qais.yousef@arm.com> If this gets accepted as-is, I'll send a patch to improve on this. Thanks -- Qais Yousef
Hi! On 09/04/2021 17:33, Qais Yousef wrote: > I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't > work out for you? I struggle to see how this is better and why it was hard to > incorporate my suggestion. > > For example > > - old = ftrace_call_replace(ip, adjust_address(rec, addr)); > +#ifdef CONFIG_ARM_MODULE_PLTS > + /* mod is only supplied during module loading */ > + if (!mod) > + mod = rec->arch.mod; > + else > + rec->arch.mod = mod; > +#endif > + > + old = ftrace_call_replace(ip, aaddr, > + !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod); > +#ifdef CONFIG_ARM_MODULE_PLTS > + if (!old && mod) { > + aaddr = get_module_plt(mod, ip, aaddr); > + old = ftrace_call_replace(ip, aaddr, true); > + } > +#endif > + > > There's an ifdef, followed by a code that embeds > !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/ No, it's actually two small ifdefed blocks added before and after an original call, which parameters have been modified as well. The issue with arch.mod was explained by Steven Rostedt, maybe you've missed his email. > And there was no need to make the new warn arg visible all the way to > ftrace_call_repalce() and all of its users. > > FWIW > > Tested-by: Qais Yousef <qais.yousef@arm.com>
Hi Alexander Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in your future postings. On 04/12/21 08:28, Alexander Sverdlin wrote: > Hi! > > On 09/04/2021 17:33, Qais Yousef wrote: > > I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't > > work out for you? I struggle to see how this is better and why it was hard to > > incorporate my suggestion. > > > > For example > > > > - old = ftrace_call_replace(ip, adjust_address(rec, addr)); > > +#ifdef CONFIG_ARM_MODULE_PLTS > > + /* mod is only supplied during module loading */ > > + if (!mod) > > + mod = rec->arch.mod; > > + else > > + rec->arch.mod = mod; > > +#endif > > + > > + old = ftrace_call_replace(ip, aaddr, > > + !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod); > > +#ifdef CONFIG_ARM_MODULE_PLTS > > + if (!old && mod) { > > + aaddr = get_module_plt(mod, ip, aaddr); > > + old = ftrace_call_replace(ip, aaddr, true); > > + } > > +#endif > > + > > > > There's an ifdef, followed by a code that embeds > > !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/ > > No, it's actually two small ifdefed blocks added before and after an original call, > which parameters have been modified as well. The issue with arch.mod was explained > by Steven Rostedt, maybe you've missed his email. If you're referring to arch.mod having to be protected by the ifdef I did address that. Please look at my patch. My comment here refers to the ugliness of this ifdefery. Introducing 2 simple wrapper functions would address that as I've demonstrated in my suggestion/patch. Thanks -- Qais Yousef
On 4/12/2021 4:08 AM, Qais Yousef wrote: > Hi Alexander > > Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in > your future postings. > > On 04/12/21 08:28, Alexander Sverdlin wrote: >> Hi! >> >> On 09/04/2021 17:33, Qais Yousef wrote: >>> I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't >>> work out for you? I struggle to see how this is better and why it was hard to >>> incorporate my suggestion. >>> >>> For example >>> >>> - old = ftrace_call_replace(ip, adjust_address(rec, addr)); >>> +#ifdef CONFIG_ARM_MODULE_PLTS >>> + /* mod is only supplied during module loading */ >>> + if (!mod) >>> + mod = rec->arch.mod; >>> + else >>> + rec->arch.mod = mod; >>> +#endif >>> + >>> + old = ftrace_call_replace(ip, aaddr, >>> + !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod); >>> +#ifdef CONFIG_ARM_MODULE_PLTS >>> + if (!old && mod) { >>> + aaddr = get_module_plt(mod, ip, aaddr); >>> + old = ftrace_call_replace(ip, aaddr, true); >>> + } >>> +#endif >>> + >>> >>> There's an ifdef, followed by a code that embeds >>> !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/ >> >> No, it's actually two small ifdefed blocks added before and after an original call, >> which parameters have been modified as well. The issue with arch.mod was explained >> by Steven Rostedt, maybe you've missed his email. > > If you're referring to arch.mod having to be protected by the ifdef I did > address that. Please look at my patch. > > My comment here refers to the ugliness of this ifdefery. Introducing 2 simple > wrapper functions would address that as I've demonstrated in my > suggestion/patch. What is the plan to move forward with this patch series, should v8 be submitted into RMK's patch tracker and improved upon from there, or do you feel like your suggestion needs to be addressed right away?
On 04/19/21 14:54, Florian Fainelli wrote: > > > On 4/12/2021 4:08 AM, Qais Yousef wrote: > > Hi Alexander > > > > Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in > > your future postings. > > > > On 04/12/21 08:28, Alexander Sverdlin wrote: > >> Hi! > >> > >> On 09/04/2021 17:33, Qais Yousef wrote: > >>> I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't > >>> work out for you? I struggle to see how this is better and why it was hard to > >>> incorporate my suggestion. > >>> > >>> For example > >>> > >>> - old = ftrace_call_replace(ip, adjust_address(rec, addr)); > >>> +#ifdef CONFIG_ARM_MODULE_PLTS > >>> + /* mod is only supplied during module loading */ > >>> + if (!mod) > >>> + mod = rec->arch.mod; > >>> + else > >>> + rec->arch.mod = mod; > >>> +#endif > >>> + > >>> + old = ftrace_call_replace(ip, aaddr, > >>> + !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod); > >>> +#ifdef CONFIG_ARM_MODULE_PLTS > >>> + if (!old && mod) { > >>> + aaddr = get_module_plt(mod, ip, aaddr); > >>> + old = ftrace_call_replace(ip, aaddr, true); > >>> + } > >>> +#endif > >>> + > >>> > >>> There's an ifdef, followed by a code that embeds > >>> !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/ > >> > >> No, it's actually two small ifdefed blocks added before and after an original call, > >> which parameters have been modified as well. The issue with arch.mod was explained > >> by Steven Rostedt, maybe you've missed his email. > > > > If you're referring to arch.mod having to be protected by the ifdef I did > > address that. Please look at my patch. > > > > My comment here refers to the ugliness of this ifdefery. Introducing 2 simple > > wrapper functions would address that as I've demonstrated in my > > suggestion/patch. > > What is the plan to move forward with this patch series, should v8 be > submitted into RMK's patch tracker and improved upon from there, or do > you feel like your suggestion needs to be addressed right away? There's no objection from my side to submitting this and improve later. Thanks -- Qais Yousef
On 4/19/21 3:34 PM, Qais Yousef wrote: > On 04/19/21 14:54, Florian Fainelli wrote: >> >> >> On 4/12/2021 4:08 AM, Qais Yousef wrote: >>> Hi Alexander >>> >>> Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in >>> your future postings. >>> >>> On 04/12/21 08:28, Alexander Sverdlin wrote: >>>> Hi! >>>> >>>> On 09/04/2021 17:33, Qais Yousef wrote: >>>>> I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't >>>>> work out for you? I struggle to see how this is better and why it was hard to >>>>> incorporate my suggestion. >>>>> >>>>> For example >>>>> >>>>> - old = ftrace_call_replace(ip, adjust_address(rec, addr)); >>>>> +#ifdef CONFIG_ARM_MODULE_PLTS >>>>> + /* mod is only supplied during module loading */ >>>>> + if (!mod) >>>>> + mod = rec->arch.mod; >>>>> + else >>>>> + rec->arch.mod = mod; >>>>> +#endif >>>>> + >>>>> + old = ftrace_call_replace(ip, aaddr, >>>>> + !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod); >>>>> +#ifdef CONFIG_ARM_MODULE_PLTS >>>>> + if (!old && mod) { >>>>> + aaddr = get_module_plt(mod, ip, aaddr); >>>>> + old = ftrace_call_replace(ip, aaddr, true); >>>>> + } >>>>> +#endif >>>>> + >>>>> >>>>> There's an ifdef, followed by a code that embeds >>>>> !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/ >>>> >>>> No, it's actually two small ifdefed blocks added before and after an original call, >>>> which parameters have been modified as well. The issue with arch.mod was explained >>>> by Steven Rostedt, maybe you've missed his email. >>> >>> If you're referring to arch.mod having to be protected by the ifdef I did >>> address that. Please look at my patch. >>> >>> My comment here refers to the ugliness of this ifdefery. Introducing 2 simple >>> wrapper functions would address that as I've demonstrated in my >>> suggestion/patch. >> >> What is the plan to move forward with this patch series, should v8 be >> submitted into RMK's patch tracker and improved upon from there, or do >> you feel like your suggestion needs to be addressed right away? > > There's no objection from my side to submitting this and improve later. OK, thanks! Alexander, do you mind sending these patches to RMK's patch tracker: https://www.armlinux.org.uk/developer/patches/? Thank you!
Hi Florian! On 04/05/2021 21:11, Florian Fainelli wrote: >>> What is the plan to move forward with this patch series, should v8 be >>> submitted into RMK's patch tracker and improved upon from there, or do >>> you feel like your suggestion needs to be addressed right away? >> There's no objection from my side to submitting this and improve later. > OK, thanks! Alexander, do you mind sending these patches to RMK's patch > tracker: https://www.armlinux.org.uk/developer/patches/? Done!
From: Alexander Sverdlin <alexander.sverdlin@nokia.com> FTRACE's function tracer currently doesn't always work on ARM with MODULE_PLT option enabled. If the module is loaded too far, FTRACE's code modifier cannot cope with introduced veneers and turns the function tracer off globally. ARM64 already has a solution for the problem, refer to the following patches: arm64: ftrace: emit ftrace-mod.o contents through code arm64: module-plts: factor out PLT generation code for ftrace arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels arm64: ftrace: fix building without CONFIG_MODULES arm64: ftrace: add support for far branches to dynamic ftrace arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() But the presented ARM variant has just a half of the footprint in terms of the changed LoCs. It also retains the code validation-before-modification instead of switching it off. Changelog: v8: * Add warn suppress parameter to arm_gen_branch_link() v7: * rebased v6: * rebased v5: * BUILD_BUG_ON() ensures fixed_plts[] always fits one PLT block * use "for" loop instead of "while" * scripts/recordmcount is filtering reloc types v4: * Fixed build without CONFIG_FUNCTION_TRACER * Reorganized pre-allocated PLTs handling in get_module_plt(), now compiler eliminates the whole FTRACE-related handling code if ARRAY_SIZE(fixed_plts) == 0 v3: * Only extend struct dyn_arch_ftrace when ARM_MODULE_PLTS is enabled v2: * As suggested by Steven Rostedt, refrain from tree-wide API modification, save module pointer in struct dyn_arch_ftrace instead (PowerPC way) Alexander Sverdlin (3): ARM: PLT: Move struct plt_entries definition to header ARM: Add warn suppress parameter to arm_gen_branch_link() ARM: ftrace: Add MODULE_PLTS support arch/arm/include/asm/ftrace.h | 3 +++ arch/arm/include/asm/insn.h | 8 +++---- arch/arm/include/asm/module.h | 10 +++++++++ arch/arm/kernel/ftrace.c | 46 +++++++++++++++++++++++++++++++++------- arch/arm/kernel/insn.c | 19 +++++++++-------- arch/arm/kernel/module-plts.c | 49 +++++++++++++++++++++++++++++++++---------- 6 files changed, 103 insertions(+), 32 deletions(-)