All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jens Remus" <jremus@linux.ibm.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v15 07/20] unwind_user/sframe: Wire up unwind_user to sframe
Date: Wed, 20 May 2026 16:23:45 +0000	[thread overview]
Message-ID: <20260520162345.F13D61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260520154004.3845823-8-jremus@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect FRE size calculation completely breaks SFrame parsing for functions with multiple FREs.
--

commit 8adeb8aec136e0b90e11e4b9aa74e9464240b9f3
Author: Josh Poimboeuf <jpoimboe@kernel.org>

unwind_user/sframe: Wire up unwind_user to sframe

This commit hooks up the sframe infrastructure to the unwind_user
interface. It introduces unwind_user_next_sframe() to utilize
sframe_find() and wires it into the user unwinding logic.

[ ... ]

> diff --git a/kernel/unwind/user.c b/kernel/unwind/user.c
> index 90ab3c1a205ef..1fb2724197332 100644
> --- a/kernel/unwind/user.c
> +++ b/kernel/unwind/user.c

[ ... ]

> @@ -82,6 +83,16 @@ static int unwind_user_next_fp(struct unwind_user_state *state)
>  	return unwind_user_next_common(state, &fp_frame);
>  }
>  
> +static int unwind_user_next_sframe(struct unwind_user_state *state)
> +{
> +	struct unwind_user_frame frame;
> +
> +	/* sframe expects the frame to be local storage */
> +	if (sframe_find(state->ip, &frame))

[Severity: High]
This is a pre-existing issue, but does the SFrame parsing logic calculate
the FRE size incorrectly for functions with multiple FREs?

Looking at the call chain from sframe_find() into __find_fre() and
__read_fre(), dataword_count is decremented as datawords are parsed until
it reaches 0. This is explicitly enforced by returning -EINVAL if
dataword_count is not zero.

Immediately after, the FRE size is computed using the now-zero
dataword_count:

fre->size = addr_size + 1 + (dataword_count * dataword_size);

Because dataword_count is always 0 here, the size of the datawords is
omitted from the size calculation.

When __find_fre() advances to the next FRE using fre_addr += fre->size,
will it start reading from the middle of the current FRE's datawords
instead of the next FRE header?

I note this is addressed later in the patch series by commit 9c045164b82cb
("unwind_user/sframe: Separate reading of FRE from reading of FRE data
words"), which refactors the code to avoid decrementing dataword_count.

> +		return -ENOENT;
> +	return unwind_user_next_common(state, &frame);
> +}
> +

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520154004.3845823-1-jremus@linux.ibm.com?part=7

  reply	other threads:[~2026-05-20 16:23 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20 15:39 [PATCH v15 00/20] unwind_deferred: Implement sframe handling Jens Remus
2026-05-20 15:39 ` [PATCH v15 01/20] unwind_user: Add generic and arch-specific headers to MAINTAINERS Jens Remus
2026-05-20 15:39 ` [PATCH v15 02/20] unwind_user/sframe: Add support for reading .sframe headers Jens Remus
2026-05-20 16:02   ` sashiko-bot
2026-05-21  7:58     ` Jens Remus
2026-05-20 15:39 ` [PATCH v15 03/20] unwind_user/sframe: Store .sframe section data in per-mm maple tree Jens Remus
2026-05-20 16:29   ` sashiko-bot
2026-05-21  9:39     ` Jens Remus
2026-05-21 16:08       ` Steven Rostedt
2026-05-20 15:39 ` [PATCH v15 04/20] x86/uaccess: Add unsafe_copy_from_user() implementation Jens Remus
2026-05-20 16:13   ` sashiko-bot
2026-05-20 15:39 ` [PATCH v15 05/20] unwind_user/sframe: Add support for reading .sframe contents Jens Remus
2026-05-20 16:33   ` sashiko-bot
2026-05-21  9:40     ` Jens Remus
2026-05-20 15:39 ` [PATCH v15 06/20] unwind_user/sframe: Detect .sframe sections in executables Jens Remus
2026-05-20 15:39 ` [PATCH v15 07/20] unwind_user/sframe: Wire up unwind_user to sframe Jens Remus
2026-05-20 16:23   ` sashiko-bot [this message]
2026-05-21 10:44     ` Jens Remus
2026-05-20 15:39 ` [PATCH v15 08/20] unwind_user: Stop when reaching an outermost frame Jens Remus
2026-05-20 16:01   ` sashiko-bot
2026-05-21 10:45     ` Jens Remus
2026-05-20 15:39 ` [PATCH v15 09/20] unwind_user/sframe: Add support for outermost frame indication Jens Remus
2026-05-20 16:01   ` sashiko-bot
2026-05-21 10:46     ` Jens Remus
2026-05-20 15:39 ` [PATCH v15 10/20] unwind_user/sframe: Remove .sframe section on detected corruption Jens Remus
2026-05-20 16:26   ` sashiko-bot
2026-05-20 15:39 ` [PATCH v15 11/20] unwind_user/sframe: Show file name in debug output Jens Remus
2026-05-20 16:14   ` sashiko-bot
2026-05-21 10:55     ` Jens Remus
2026-05-21 16:20       ` Steven Rostedt
2026-05-20 15:39 ` [PATCH v15 12/20] unwind_user/sframe: Add .sframe validation option Jens Remus
2026-05-20 16:15   ` sashiko-bot
2026-05-21 12:51     ` Jens Remus
2026-05-20 15:39 ` [PATCH v15 13/20] unwind_user: Enable archs that pass RA in a register Jens Remus
2026-05-20 16:21   ` sashiko-bot
2026-05-21 13:00     ` Jens Remus
2026-05-20 15:39 ` [PATCH v15 14/20] unwind_user: Flexible FP/RA recovery rules Jens Remus
2026-05-20 15:39 ` [PATCH v15 15/20] unwind_user: Flexible CFA " Jens Remus
2026-05-20 16:22   ` sashiko-bot
2026-05-21 11:33     ` Jens Remus
2026-05-20 15:40 ` [PATCH v15 16/20] unwind_user/sframe: Add support for SFrame V3 flexible FDEs Jens Remus
2026-05-20 17:04   ` sashiko-bot
2026-05-21 11:58     ` Jens Remus
2026-05-20 15:40 ` [PATCH v15 17/20] unwind_user/sframe: Separate reading of FRE from reading of FRE data words Jens Remus
2026-05-20 16:48   ` sashiko-bot
2026-05-20 15:40 ` [PATCH v15 18/20] unwind_user/sframe: Duplicate registered .sframe section data on clone/fork Jens Remus
2026-05-20 17:01   ` sashiko-bot
2026-05-21 12:05     ` Jens Remus
2026-05-20 15:40 ` [PATCH v15 19/20] unwind_user/sframe/x86: Enable sframe unwinding on x86 Jens Remus
2026-05-20 15:40 ` [PATCH v15 20/20] unwind_user/sframe: Add prctl() interface for registering .sframe sections Jens Remus
2026-05-20 16:52   ` sashiko-bot
2026-05-21 12:08     ` Jens Remus

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=20260520162345.F13D61F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jremus@linux.ibm.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.