From: Steven Rostedt <rostedt@goodmis.org>
To: Wang Han <wanghan@linux.alibaba.com>
Cc: "Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Chen Pei" <cp0613@linux.alibaba.com>,
"Andy Chiu" <andybnac@gmail.com>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Deepak Gupta" <debug@rivosinc.com>,
"Puranjay Mohan" <puranjay@kernel.org>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
"Jiri Kosina" <jikos@kernel.org>,
"Miroslav Benes" <mbenes@suse.cz>,
"Petr Mladek" <pmladek@suse.com>,
"Joe Lawrence" <joe.lawrence@redhat.com>,
"Shuah Khan" <shuah@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
oliver.yang@linux.alibaba.com, xueshuai@linux.alibaba.com,
zhuo.song@linux.alibaba.com, jkchen@linux.alibaba.com,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 1/8] scripts/sorttable: Handle RISC-V patchable ftrace entries
Date: Thu, 28 May 2026 09:21:53 -0400 [thread overview]
Message-ID: <20260528092153.3dde1f75@fedora> (raw)
In-Reply-To: <20260528082310.1994388-2-wanghan@linux.alibaba.com>
On Thu, 28 May 2026 16:23:03 +0800
Wang Han <wanghan@linux.alibaba.com> 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) <rostedt@goodmis.org>
> Link: https://lore.kernel.org/all/20260527113028.4b21a5de@fedora/
> Signed-off-by: Wang Han <wanghan@linux.alibaba.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <rostedt@goodmis.org>
To: Wang Han <wanghan@linux.alibaba.com>
Cc: "Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Chen Pei" <cp0613@linux.alibaba.com>,
"Andy Chiu" <andybnac@gmail.com>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Deepak Gupta" <debug@rivosinc.com>,
"Puranjay Mohan" <puranjay@kernel.org>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
"Jiri Kosina" <jikos@kernel.org>,
"Miroslav Benes" <mbenes@suse.cz>,
"Petr Mladek" <pmladek@suse.com>,
"Joe Lawrence" <joe.lawrence@redhat.com>,
"Shuah Khan" <shuah@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
oliver.yang@linux.alibaba.com, xueshuai@linux.alibaba.com,
zhuo.song@linux.alibaba.com, jkchen@linux.alibaba.com,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 1/8] scripts/sorttable: Handle RISC-V patchable ftrace entries
Date: Thu, 28 May 2026 09:21:53 -0400 [thread overview]
Message-ID: <20260528092153.3dde1f75@fedora> (raw)
In-Reply-To: <20260528082310.1994388-2-wanghan@linux.alibaba.com>
On Thu, 28 May 2026 16:23:03 +0800
Wang Han <wanghan@linux.alibaba.com> 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) <rostedt@goodmis.org>
> Link: https://lore.kernel.org/all/20260527113028.4b21a5de@fedora/
> Signed-off-by: Wang Han <wanghan@linux.alibaba.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-05-28 13:22 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 12:35 [PATCH 0/8] riscv: Add reliable stack unwinding for livepatch Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-27 12:35 ` [PATCH 1/8] scripts/sorttable: Handle RISC-V patchable ftrace entries Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-27 15:30 ` Steven Rostedt
2026-05-27 15:30 ` Steven Rostedt
2026-05-28 5:38 ` Wang Han
2026-05-28 5:38 ` Wang Han
2026-06-03 7:14 ` Chen Pei
2026-06-03 7:14 ` Chen Pei
2026-05-27 12:35 ` [PATCH 2/8] riscv: stacktrace: Add frame record metadata Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-27 12:35 ` [PATCH 3/8] riscv: stacktrace: disable KASAN instrumentation for stacktrace.o Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-27 12:35 ` [PATCH 4/8] riscv: ftrace: always preserve s0 in dynamic ftrace register frame Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-27 12:35 ` [PATCH 5/8] riscv: stacktrace: introduce stack-bound tracking helpers Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-27 12:35 ` [PATCH 6/8] riscv: stacktrace: switch to frame-pointer based unwinder Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-27 12:35 ` [PATCH 7/8] riscv: Kconfig: enable HAVE_RELIABLE_STACKTRACE and HAVE_LIVEPATCH Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-27 12:35 ` [PATCH 8/8] selftests/livepatch: Add RISC-V syscall wrapper prefix Wang Han
2026-05-27 12:35 ` Wang Han
2026-05-28 8:23 ` [PATCH v2 0/8] riscv: Add reliable stack unwinding for livepatch Wang Han
2026-05-28 8:23 ` Wang Han
2026-05-28 8:23 ` [PATCH v2 1/8] scripts/sorttable: Handle RISC-V patchable ftrace entries Wang Han
2026-05-28 8:23 ` Wang Han
2026-05-28 13:21 ` Steven Rostedt [this message]
2026-05-28 13:21 ` Steven Rostedt
2026-06-01 6:17 ` Shuai Xue
2026-06-01 6:17 ` Shuai Xue
2026-06-01 13:57 ` Steven Rostedt
2026-06-01 13:57 ` Steven Rostedt
2026-06-03 2:10 ` Shuai Xue
2026-06-03 2:10 ` Shuai Xue
2026-05-28 8:23 ` [PATCH v2 2/8] riscv: stacktrace: Add frame record metadata Wang Han
2026-05-28 8:23 ` Wang Han
2026-06-02 11:18 ` Shuai Xue
2026-06-02 11:18 ` Shuai Xue
2026-05-28 8:23 ` [PATCH v2 3/8] riscv: stacktrace: disable KASAN instrumentation for stacktrace.o Wang Han
2026-05-28 8:23 ` Wang Han
2026-06-02 11:22 ` Shuai Xue
2026-06-02 11:22 ` Shuai Xue
2026-05-28 8:23 ` [PATCH v2 4/8] riscv: ftrace: always preserve s0 in dynamic ftrace register frame Wang Han
2026-05-28 8:23 ` Wang Han
2026-06-02 11:37 ` Shuai Xue
2026-06-02 11:37 ` Shuai Xue
2026-05-28 8:23 ` [PATCH v2 5/8] riscv: stacktrace: introduce stack-bound tracking helpers Wang Han
2026-05-28 8:23 ` Wang Han
2026-06-03 1:23 ` Shuai Xue
2026-06-03 1:23 ` Shuai Xue
2026-05-28 8:23 ` [PATCH v2 6/8] riscv: stacktrace: switch to frame-pointer based unwinder Wang Han
2026-05-28 8:23 ` Wang Han
2026-06-03 1:35 ` Shuai Xue
2026-06-03 1:35 ` Shuai Xue
2026-05-28 8:23 ` [PATCH v2 7/8] riscv: Kconfig: enable HAVE_RELIABLE_STACKTRACE and HAVE_LIVEPATCH Wang Han
2026-05-28 8:23 ` Wang Han
2026-06-03 1:49 ` Shuai Xue
2026-06-03 1:49 ` Shuai Xue
2026-05-28 8:23 ` [PATCH v2 8/8] selftests/livepatch: Add RISC-V syscall wrapper prefix Wang Han
2026-05-28 8:23 ` Wang Han
2026-05-28 13:33 ` Marcos Paulo de Souza
2026-05-28 13:33 ` Marcos Paulo de Souza
2026-06-03 1:54 ` Shuai Xue
2026-06-03 1:54 ` Shuai Xue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260528092153.3dde1f75@fedora \
--to=rostedt@goodmis.org \
--cc=acme@kernel.org \
--cc=alex@ghiti.fr \
--cc=andybnac@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn@rivosinc.com \
--cc=catalin.marinas@arm.com \
--cc=conor.dooley@microchip.com \
--cc=cp0613@linux.alibaba.com \
--cc=debug@rivosinc.com \
--cc=jikos@kernel.org \
--cc=jkchen@linux.alibaba.com \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mbenes@suse.cz \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=oliver.yang@linux.alibaba.com \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pjw@kernel.org \
--cc=pmladek@suse.com \
--cc=puranjay@kernel.org \
--cc=shuah@kernel.org \
--cc=wanghan@linux.alibaba.com \
--cc=xueshuai@linux.alibaba.com \
--cc=zhuo.song@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.