Re: [PATCH 1/2] riscv: stacktrace: do not report the walker's own frame from arch_stack_walk()

[Shuai Xue <xueshuai@linux.alibaba.com>]

On 10/10/26 9:27 PM, Karl Mehltretter wrote:
> stack_trace_save() uses skipnr + 1 because arch_stack_walk() is expected
> to first report the return into stack_trace_save(). With FRAME_POINTER,
> the RISC-V arch_stack_walk() calls walk_stackframe(), which starts from
> its own frame and first reports the return into arch_stack_walk().
> stack_trace_save() therefore starts one frame too early. For example,
> page_owner records begin at __set_page_owner() instead of the allocation
> site.
> 
> Move the walker into an always-inlined helper and call it directly from
> arch_stack_walk(). Keep walk_stackframe() as a wrapper for its existing
> callers.
> 
> return_address() skips level + 3 entries, while the arm64 implementation
> skips level + 2. After removing the extra frame, use level + 2 so
> ftrace_return_address() and CALLER_ADDR results do not shift by one caller.
> 
> Fixes: 6a00ef449370 ("riscv: eliminate unreliable __builtin_frame_address(1)")
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
> Tested with the KUnit suite from patch 2 on QEMU's virt machine, clang 22
> (LLVM=1), on af32da41b032:
> 
>    mainline                        stack_trace_save 0/3, return_address 2/2
>    stacktrace.c change alone       stack_trace_save 3/3, return_address 0/2
>    this patch                      stack_trace_save 3/3, return_address 2/2
> 
> A BeagleV Ahead (TH1520) booted with this patch passes all five cases.
> The stack_trace_save() result on mainline (0/3) was also reproduced with
> GCC 15.2 and QEMU 10.2.1.
> 
> Without CONFIG_FRAME_POINTER the walker scans the stack for anything that
> looks like a text address and its start frame is not exact before or
> after this patch. What return_address() returns there is unchanged: the
> walk loses one leading entry and the skip count goes down by one.
> 
> The reliable unwinder series [1] rewrites this walker and has the correct
> start frame for stack_trace_save() as a side effect, but leaves
> return_address() at level + 3. This patch conflicts with 5/7 of that
> series; if that goes in first, only the return_address.c hunk is needed.
> 
> [1] https://lore.kernel.org/r/20260914092648.51254-1-xueshuai@linux.alibaba.com
Hi Karl,

Now that 7.4-rc1 is out and neither your two patches nor the reliable
unwinder series made this merge window, I'm preparing v7 of the series
for the next one.

Are you OK with folding your patches into the livepatch series rather
than keeping two conflicting walkers in flight?

Thanks.
Shuai