From: Steven Rostedt <rostedt@goodmis.org>
To: Yuanhe Shu <xiangzao@linux.alibaba.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] x86/stacktrace: Mark arch_stack_walk() and unwinder functions notrace
Date: Mon, 6 Jul 2026 10:57:15 -0400 [thread overview]
Message-ID: <20260706105715.769ba488@gandalf.local.home> (raw)
In-Reply-To: <20260706095445.1683434-1-xiangzao@linux.alibaba.com>
On Mon, 6 Jul 2026 17:54:45 +0800
Yuanhe Shu <xiangzao@linux.alibaba.com> wrote:
> When the function tracer's func_stack_trace option and the function graph
> profiler (function_profile_enabled) are both active, a recursive ftrace
> reentrance can occur, leading to a hard lockup. This was observed during
> ftrace selftest (ftracetest-ktap) execution:
>
> watchdog: Watchdog detected hard LOCKUP on cpu 204
> RIP: profile_graph_entry+0xa0/0x160
> Call Trace:
> function_graph_enter+0xc9/0x120
> arch_ftrace_ops_list_func+0x112/0x230
> ftrace_call+0x5/0x44
> unwind_next_frame+0x5/0x870 <-- traced by ftrace
> arch_stack_walk+0x88/0xf0
> stack_trace_save+0x4b/0x70
> __ftrace_trace_stack+0x12e/0x170
> function_stack_trace_call+0x7c/0xa0
> arch_ftrace_ops_list_func+0x112/0x230
> ftrace_call+0x5/0x44
> irqtime_account_irq+0x5/0xb0
> __irq_exit_rcu+0x12/0xc0
> ...
>
> The root cause is a recursive ftrace reentrance:
> function_stack_trace_call() invokes __trace_stack() ->
> arch_stack_walk() -> unwind_next_frame() to capture a backtrace.
> Since the unwinder functions (__unwind_start(),
> unwind_next_frame(), unwind_get_return_address(),
> unwind_get_return_address_ptr()) are not marked notrace, the
> function graph tracer instruments them, re-entering the ftrace
> infrastructure from within an ftrace callback. This results in a
> hard lockup with interrupts disabled, detected by the watchdog NMI.
I'm fine with this change, but I'm wondering why the recursion protection
didn't catch this. There may be a missing check somewhere. I'll ack this
change, but I also want to add the check that would have prevented this
lockup.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
prev parent reply other threads:[~2026-07-06 14:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 9:54 [PATCH] x86/stacktrace: Mark arch_stack_walk() and unwinder functions notrace Yuanhe Shu
2026-07-06 14:57 ` Steven Rostedt [this message]
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=20260706105715.769ba488@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xiangzao@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox