From: Jens Remus <jremus@linux.ibm.com>
To: Dylan Hatch <dylanbhatch@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Weinan Liu <wnliu@google.com>, Will Deacon <will@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Indu Bhagat <indu.bhagat@oracle.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jiri Kosina <jikos@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Prasanna Kumar T S M <ptsm@linux.microsoft.com>,
Puranjay Mohan <puranjay@kernel.org>, Song Liu <song@kernel.org>,
joe.lawrence@redhat.com, linux-toolchains@vger.kernel.org,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/8] sframe: Allow kernelspace sframe sections.
Date: Tue, 14 Apr 2026 14:09:42 +0200 [thread overview]
Message-ID: <e087a768-507d-4ac2-8875-ab7c522420bd@linux.ibm.com> (raw)
In-Reply-To: <20260406185000.1378082-2-dylanbhatch@google.com>
Hello Dylan!
On 4/6/2026 8:49 PM, Dylan Hatch wrote:
> Generalize the sframe lookup code to support kernelspace sections. This
> is done by defining a SFRAME_LOOKUP option that can be activated
> separate from UNWIND_USER_SFRAME, as there will be other clients to this
> library than just userspace unwind.
Nit: s/UNWIND_USER_SFRAME/HAVE_UNWIND_USER_SFRAME/
This actually uses the following two new Kconfig options (with
SFRAME_UNWINDER technically being introduced in the next patch):
SFRAME_LOOKUP
SFRAME_UNWINDER
IIUC SFRAME_UNWINDER is the kernel counterpart to the existing
HAVE_UNWIND_USER_SFRAME. Would it therefore make sense to align the
naming as follows?
HAVE_UNWIND_KERNEL_SFRAME (instead of SFRAME_UNWINDER)
HAVE_UNWIND_USER_SFRAME
> Sframe section location is now tracked in a separate sec_type field to
> determine whether user-access functions are necessary to read the sframe
> data. Relevant type delarations are moved and renamed to reflect the
> non-user sframe support.
>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
> diff --git a/arch/Kconfig b/arch/Kconfig
> @@ -486,6 +486,9 @@ config AS_SFRAME3
> def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,-Wa$(comma)--gsframe-3)
> select AS_SFRAME
>
> +config SFRAME_LOOKUP
> + bool
> +
> config UNWIND_USER
> bool
>
> @@ -496,6 +499,7 @@ config HAVE_UNWIND_USER_FP
> config HAVE_UNWIND_USER_SFRAME
> bool
> select UNWIND_USER
> + select SFRAME_LOOKUP
>
> config SFRAME_VALIDATION
> bool "Enable .sframe section debugging"
IIUC SFRAME_LOOKUP only exists to pull in the common (kernel and user)
sframe lookup code if SFRAME_UNWINDER and/or UNWIND_USER_SFRAME are
enabled. Given there is currently no other use case than kernel/user
stacktrace unwinding, would it make sense to rename it as follows to
group all of the related options with the UNWIND prefix?
UNWIND_SFRAME[_LOOKUP]
> diff --git a/include/linux/sframe.h b/include/linux/sframe.h
> @@ -4,36 +4,85 @@
>
> #include <linux/mm_types.h>
> #include <linux/srcu.h>
> -#include <linux/unwind_user_types.h>
>
> -#ifdef CONFIG_HAVE_UNWIND_USER_SFRAME
> +#define UNWIND_RULE_DEREF BIT(31)
> +
> +enum unwind_cfa_rule {
> + UNWIND_CFA_RULE_SP_OFFSET, /* CFA = SP + offset */
> + UNWIND_CFA_RULE_FP_OFFSET, /* CFA = FP + offset */
> + UNWIND_CFA_RULE_REG_OFFSET, /* CFA = reg + offset */
> + /* DEREF variants */
> + UNWIND_CFA_RULE_REG_OFFSET_DEREF = /* CFA = *(reg + offset) */
> + UNWIND_CFA_RULE_REG_OFFSET | UNWIND_RULE_DEREF,
> +};
> +
> +struct unwind_cfa_rule_data {
> + enum unwind_cfa_rule rule;
> + s32 offset;
> + unsigned int regnum;
> +};
> +
> +enum unwind_rule {
> + UNWIND_RULE_RETAIN, /* entity = entity */
> + UNWIND_RULE_CFA_OFFSET, /* entity = CFA + offset */
> + UNWIND_RULE_REG_OFFSET, /* entity = register + offset */
> + /* DEREF variants */
> + UNWIND_RULE_CFA_OFFSET_DEREF = /* entity = *(CFA + offset) */
> + UNWIND_RULE_CFA_OFFSET | UNWIND_RULE_DEREF,
> + UNWIND_RULE_REG_OFFSET_DEREF = /* entity = *(register + offset) */
> + UNWIND_RULE_REG_OFFSET | UNWIND_RULE_DEREF,
> +};
> +
> +struct unwind_rule_data {
> + enum unwind_rule rule;
> + s32 offset;
> + unsigned int regnum;
> +};
> +
> +struct unwind_frame {
> + struct unwind_cfa_rule_data cfa;
> + struct unwind_rule_data ra;
> + struct unwind_rule_data fp;
> + bool outermost;
> +};
You are moving (and renaming to generalize for kernel and user unwind
use) the above definitions from include/linux/unwind_user_types.h to
include/linux/sframe.h. Given the definitions are used in
kernel/unwind/user.c for FP and SFRAME unwinding this seems wrong to
me. The definitions should better be moved (and renamed as you did)
into a new include/linux/unwind_types.h (or the like).
> diff --git a/include/linux/unwind_user_types.h b/include/linux/unwind_user_types.h
> @@ -27,47 +27,6 @@ struct unwind_stacktrace {
> unsigned long *entries;
> };
>
> -#define UNWIND_USER_RULE_DEREF BIT(31)
> -
> -enum unwind_user_cfa_rule {
> - UNWIND_USER_CFA_RULE_SP_OFFSET, /* CFA = SP + offset */
> - UNWIND_USER_CFA_RULE_FP_OFFSET, /* CFA = FP + offset */
> - UNWIND_USER_CFA_RULE_REG_OFFSET, /* CFA = reg + offset */
> - /* DEREF variants */
> - UNWIND_USER_CFA_RULE_REG_OFFSET_DEREF = /* CFA = *(reg + offset) */
> - UNWIND_USER_CFA_RULE_REG_OFFSET | UNWIND_USER_RULE_DEREF,
> -};
> -
> -struct unwind_user_cfa_rule_data {
> - enum unwind_user_cfa_rule rule;
> - s32 offset;
> - unsigned int regnum;
> -};
> -
> -enum unwind_user_rule {
> - UNWIND_USER_RULE_RETAIN, /* entity = entity */
> - UNWIND_USER_RULE_CFA_OFFSET, /* entity = CFA + offset */
> - UNWIND_USER_RULE_REG_OFFSET, /* entity = register + offset */
> - /* DEREF variants */
> - UNWIND_USER_RULE_CFA_OFFSET_DEREF = /* entity = *(CFA + offset) */
> - UNWIND_USER_RULE_CFA_OFFSET | UNWIND_USER_RULE_DEREF,
> - UNWIND_USER_RULE_REG_OFFSET_DEREF = /* entity = *(register + offset) */
> - UNWIND_USER_RULE_REG_OFFSET | UNWIND_USER_RULE_DEREF,
> -};
> -
> -struct unwind_user_rule_data {
> - enum unwind_user_rule rule;
> - s32 offset;
> - unsigned int regnum;
> -};
> -
> -struct unwind_user_frame {
> - struct unwind_user_cfa_rule_data cfa;
> - struct unwind_user_rule_data ra;
> - struct unwind_user_rule_data fp;
> - bool outermost;
> -};
> -
> struct unwind_user_state {
> unsigned long ip;
> unsigned long sp;
> diff --git a/kernel/unwind/Makefile b/kernel/unwind/Makefile
> @@ -1,2 +1,2 @@
> obj-$(CONFIG_UNWIND_USER) += user.o deferred.o
> - obj-$(CONFIG_HAVE_UNWIND_USER_SFRAME) += sframe.o
> + obj-$(CONFIG_SFRAME_LOOKUP) += sframe.o
> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> @@ -44,8 +43,6 @@ struct sframe_fre_internal {
> unsigned char dw_size;
> };
>
> -DEFINE_STATIC_SRCU(sframe_srcu);
> -
> static __always_inline unsigned char fre_type_to_size(unsigned char fre_type)
> {
> if (fre_type > 2)
> @@ -60,6 +57,78 @@ static __always_inline unsigned char dataword_size_enum_to_size(unsigned char da
> return 1 << dataword_size;
> }
>
> +#ifdef CONFIG_HAVE_UNWIND_USER_SFRAME
> +
> +DEFINE_STATIC_SRCU(sframe_srcu);
> +
> +#define UNSAFE_USER_COPY(to, from, size, label) \
> + unsafe_copy_from_user(to, (void __user *)from, size, label)
> +
> +#define UNSAFE_USER_GET(to, from, type, label) \
> + unsafe_get_user(to, (type __user *)from, label)
> +
> +#else /* !CONFIG_HAVE_UNWIND_USER_SFRAME */
> +
> +#define UNSAFE_USER_COPY(to, from, size, label) do { \
> + (void)to; (void)from; (void)size; \
> + goto label; \
> +} while (0)
> +
> +#define UNSAFE_USER_GET(to, from, type, label) do { \
> + (void)to; (void)from; \
> + goto label; \
> +} while (0)
> +
> +#endif /* !CONFIG_HAVE_UNWIND_USER_SFRAME */
> +
> +#ifdef CONFIG_SFRAME_UNWINDER
> +
> +#define KERNEL_COPY(to, from, size) memcpy(to, (void *)from, size)
> +#define KERNEL_GET(to, from, type) ({ (to) = *(type *)(from); })
> +
> +#else /* !CONFIG_SFRAME_UNWINDER */
> +
> +#define KERNEL_COPY(to, from, size) do { \
> + (void)(to); (void)(from); (void)size; \
> + return -EFAULT; \
> +} while (0)
> +
> +#define KERNEL_GET(to, from, type) do { \
> + (void)(to); (void)(from); \
> + return -EFAULT; \
> +} while (0)
The error return value in above dummy implementations is never used
(see DATA_COPY() and DATA_GET() below). Maybe better define the KERNEL
flavors with the same interface as the UNSAFE_USER ones (with error
label) and have the dummy implementations goto that label?
> +
> +
Nit: Two instead of one empty line.
> +#endif /* !CONFIG_SFRAME_UNWINDER */
> +
> +#define DATA_COPY(sec, to, from, size, label) \
> +({ \
> + switch (sec->sec_type) { \
> + case SFRAME_KERNEL: \
> + KERNEL_COPY(to, from, size); \
> + break; \
> + case SFRAME_USER: \
> + UNSAFE_USER_COPY(to, from, size, label); \
> + break; \
> + default: \
> + return -EFAULT; \
> + } \
> +})
> +
> +#define DATA_GET(sec, to, from, type, label) \
> +({ \
> + switch (sec->sec_type) { \
> + case SFRAME_KERNEL: \
> + KERNEL_GET(to, from, type); \
> + break; \
> + case SFRAME_USER: \
> + UNSAFE_USER_GET(to, from, type, label); \
> + break; \
> + default: \
> + return -EFAULT; \
> + } \
> +})
> +
> static __always_inline int __read_fde(struct sframe_section *sec,
> unsigned int fde_num,
> struct sframe_fde_internal *fde)
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
next prev parent reply other threads:[~2026-04-14 12:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-06 18:49 [PATCH v3 0/8] unwind, arm64: add sframe unwinder for kernel Dylan Hatch
2026-04-06 18:49 ` [PATCH v3 1/8] sframe: Allow kernelspace sframe sections Dylan Hatch
2026-04-14 12:09 ` Jens Remus [this message]
2026-04-06 18:49 ` [PATCH v3 2/8] arm64, unwind: build kernel with sframe V3 info Dylan Hatch
2026-04-06 21:36 ` Randy Dunlap
2026-04-14 12:43 ` Jens Remus
2026-04-18 0:20 ` Dylan Hatch
2026-04-20 12:16 ` Jens Remus
2026-04-20 12:44 ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 3/8] arm64: entry: add unwind info for various kernel entries Dylan Hatch
2026-04-16 14:09 ` Jens Remus
2026-04-16 16:49 ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 4/8] sframe: Provide PC lookup for vmlinux .sframe section Dylan Hatch
2026-04-16 15:10 ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 5/8] sframe: Allow unsorted FDEs Dylan Hatch
2026-04-16 14:57 ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 6/8] arm64/module, sframe: Add sframe support for modules Dylan Hatch
2026-04-17 14:07 ` Jens Remus
2026-04-20 9:54 ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION Dylan Hatch
2026-04-16 15:04 ` Jens Remus
2026-04-20 5:02 ` Dylan Hatch
2026-04-20 12:30 ` Jens Remus
2026-04-21 1:29 ` Dylan Hatch
2026-04-21 8:33 ` Jens Remus
2026-04-06 18:50 ` [PATCH v3 8/8] unwind: arm64: Use sframe to unwind interrupt frames Dylan Hatch
2026-04-17 15:45 ` Jens Remus
2026-04-20 5:56 ` Dylan Hatch
2026-04-20 8:42 ` Jens Remus
2026-04-14 16:10 ` [PATCH v3 0/8] unwind, arm64: add sframe unwinder for kernel 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=e087a768-507d-4ac2-8875-ab7c522420bd@linux.ibm.com \
--to=jremus@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=dylanbhatch@google.com \
--cc=indu.bhagat@oracle.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=ptsm@linux.microsoft.com \
--cc=puranjay@kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=song@kernel.org \
--cc=will@kernel.org \
--cc=wnliu@google.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.