Re: [PATCH v2 1/8] scripts/sorttable: Handle RISC-V patchable ftrace entries
Steven Rostedt <[email protected]> Thu, 28 May 2026 09:21:53 -0400
| Newsgroups | org.kernel.vger.live-patching,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-trace-kernel |
|---|---|
| Message-ID | <20260528092153.3dde1f75@fedora> |
On Thu, 28 May 2026 16:23:03 +0800 Wang Han <[email protected]> wrote: > RISC-V uses -fpatchable-function-entry=8,4 when the compressed ISA is > enabled and -fpatchable-function-entry=4,2 otherwise. In both cases, the > patchable NOP area starts 8 bytes before the function symbol address. > The __mcount_loc entries therefore point at the patchable NOP area > associated with a function, while nm reports the function symbol at the > entry address used for the function range check. > > After RISC-V selected HAVE_BUILDTIME_MCOUNT_SORT, sorttable started > applying that range check at build time. Without allowing entries just > before the reported function address, the mcount sorter treats valid > RISC-V ftrace callsites as invalid weak-function entries and writes > them back as zero. The resulting kernel boots with no ftrace entries, > breaking dynamic ftrace and users such as livepatch. > > The failure is silent during the final link because zeroing weak-function > entries is an expected sorttable operation. At boot, those zero entries > are skipped by ftrace_process_locs(), so the only obvious symptom is that > the vmlinux ftrace table has lost valid callsites and ftrace users cannot > attach to them. > > CONFIG_FTRACE_SORT_STARTUP_TEST also reports the table as sorted in this > state: it only checks that the __mcount_loc entries are in ascending > order, which a fully zeroed table trivially satisfies. The original > commit relied on this check and did not see the regression. > > On an affected RISC-V QEMU boot with both CONFIG_FTRACE_SORT_STARTUP_TEST > and CONFIG_FTRACE_STARTUP_TEST enabled, the sort check still passes > while ftrace reports zero usable entries and the early selftests fail: > > [ 0.000000] ftrace section at ffffffff8101da98 sorted properly > [ 0.000000] ftrace: allocating 0 entries in 128 pages > [ 0.054999] Testing tracer function: .. no entries found ..FAILED! > [ 0.172407] tracer: function failed selftest, disabling > [ 0.178186] Failed to init function_graph tracer, init returned -19 > > Handle RISC-V like arm64 for the function-range check and allow > patchable entries up to 8 bytes before the function address. > > With this fix, a RISC-V QEMU smoke boot with ftrace startup tests shows > the vmlinux ftrace table is populated and dynamic ftrace still works: > > [ 0.000000] ftrace: allocating 46749 entries in 184 pages > [ 0.051115] Testing tracer function: PASSED > [ 1.283782] Testing dynamic ftrace: PASSED > [ 6.275456] Testing tracer function_graph: PASSED > > Fixes: 0ca1724b56af ("riscv: ftrace: select HAVE_BUILDTIME_MCOUNT_SORT") > Suggested-by: Steven Rostedt (Google) <[email protected]> > Link: https://lore.kernel.org/all/20260527113028.4b21a5de@fedora/ > Signed-off-by: Wang Han <[email protected]> Reviewed-by: Steven Rostedt <[email protected]> -- Steve