Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wang Han" <wanghan@linux.alibaba.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v3 6/8] riscv: stacktrace: switch to frame-pointer based unwinder
Date: Tue, 09 Jun 2026 08:44:06 +0000	[thread overview]
Message-ID: <20260609084407.185991F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260609063002.3943001-6-wanghan@linux.alibaba.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Comment inaccurately describes the memory location of the metadata type field.
--

commit 0eadbda136e709b7b12de76094d4f29e825575fb
Author: Wang Han <wanghan@linux.alibaba.com>

riscv: stacktrace: switch to frame-pointer based unwinder

Replace the open-coded frame-pointer walker in arch_stack_walk() with a
robust kunwind state machine. The new walker tracks stack bounds, consumes
frame records monotonically, and integrates with function graph tracing and
perf callchains.

> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 2692d3a06afa2..8fcf23b046d59 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
[ ... ]
> +/*
> + * Unwind from one frame record to the next.
> + *
> + * On RISC-V, the frame record sits at fp - sizeof(struct frame_record),
> + * immediately below the address pointed to by fp/s0. This applies to both
> + * normal frame records and metadata frame records (embedded in pt_regs).
> + *
> + * A metadata record is identified by both fp and ra being zero in the
> + * frame_record portion, with a type value following at fp + 16.
> + */

[Severity: Low]
Is the comment describing the metadata type location accurate?

It states "with a type value following at fp + 16". However, since fp points
directly above the 16-byte frame_record, and the type field immediately
follows the record in struct frame_record_meta, wouldn't the type field be
located exactly at fp rather than fp + 16?

> +static __always_inline int
> +kunwind_next_frame_record(struct kunwind_state *state)
> +{
> +	unsigned long fp = state->common.fp;
> +	struct frame_record *record;
> +	struct stack_info *info;
> +	unsigned long new_fp, new_pc;
> +	unsigned long record_base;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.194d76e3a15b.v3.riscv-livepatch.wanghan@linux.alibaba.com?part=6

  reply	other threads:[~2026-06-09  8:44 UTC|newest]

Thread overview: 46+ 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 ` [PATCH 1/8] scripts/sorttable: Handle RISC-V patchable ftrace entries Wang Han
2026-05-27 15:30   ` Steven Rostedt
2026-05-28  5:38     ` Wang Han
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 ` [PATCH 3/8] riscv: stacktrace: disable KASAN instrumentation for stacktrace.o 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 ` [PATCH 5/8] riscv: stacktrace: introduce stack-bound tracking helpers 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 ` [PATCH 7/8] riscv: Kconfig: enable HAVE_RELIABLE_STACKTRACE and HAVE_LIVEPATCH Wang Han
2026-05-27 12:35 ` [PATCH 8/8] selftests/livepatch: Add RISC-V syscall wrapper prefix Wang Han
2026-05-28  8:23 ` [PATCH v2 0/8] riscv: Add reliable stack unwinding for livepatch Wang Han
2026-06-09  6:29   ` [PATCH v3 " Wang Han
2026-06-09  6:29     ` [PATCH v3 1/8] scripts/sorttable: Handle RISC-V patchable ftrace entries Wang Han
2026-06-09  7:27       ` Martin Kaiser
2026-06-09  6:29     ` [PATCH v3 2/8] riscv: stacktrace: Add frame record metadata Wang Han
2026-06-09  6:29     ` [PATCH v3 3/8] riscv: stacktrace: disable KASAN and KCOV instrumentation for stacktrace.o Wang Han
2026-06-09  6:29     ` [PATCH v3 4/8] riscv: ftrace: always preserve s0 in dynamic ftrace register frame Wang Han
2026-06-09  6:29     ` [PATCH v3 5/8] riscv: stacktrace: introduce stack-bound tracking helpers Wang Han
2026-06-09  6:41       ` sashiko-bot
2026-06-09  6:29     ` [PATCH v3 6/8] riscv: stacktrace: switch to frame-pointer based unwinder Wang Han
2026-06-09  8:44       ` sashiko-bot [this message]
2026-06-09  6:29     ` [PATCH v3 7/8] riscv: Kconfig: enable HAVE_RELIABLE_STACKTRACE and HAVE_LIVEPATCH Wang Han
2026-06-09  6:29     ` [PATCH v3 8/8] selftests/livepatch: Add RISC-V syscall wrapper prefix Wang Han
2026-06-09  6:45       ` sashiko-bot
2026-05-28  8:23 ` [PATCH v2 1/8] scripts/sorttable: Handle RISC-V patchable ftrace entries Wang Han
2026-05-28 13:21   ` Steven Rostedt
2026-06-01  6:17   ` Shuai Xue
2026-06-01 13:57     ` Steven Rostedt
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-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-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-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-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-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-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 13:33   ` Marcos Paulo de Souza
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=20260609084407.185991F00898@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wanghan@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