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,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Ilya Leoshkevich <iii@linux.ibm.com>
Subject: Re: [PATCH v3 2/8] arm64, unwind: build kernel with sframe V3 info
Date: Tue, 14 Apr 2026 14:43:43 +0200 [thread overview]
Message-ID: <cc7f741c-41a0-4620-b5d5-3428aaa7648f@linux.ibm.com> (raw)
In-Reply-To: <20260406185000.1378082-3-dylanbhatch@google.com>
On 4/6/2026 8:49 PM, Dylan Hatch wrote:
> Build with -Wa,--gsframe-3 flags to generate a .sframe section. This
> will be used for in-kernel reliable stacktrace in cases where the frame
> pointer alone is insufficient.
>
> Currently, the sframe format only supports arm64, x86_64 and s390x
> architectures.
>
> Signed-off-by: Weinan Liu <wnliu@google.com>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
> diff --git a/MAINTAINERS b/MAINTAINERS
> @@ -27561,6 +27561,7 @@ STACK UNWINDING
> M: Josh Poimboeuf <jpoimboe@kernel.org>
> M: Steven Rostedt <rostedt@goodmis.org>
> S: Maintained
> +F: arch/*/include/asm/unwind_sframe.h
> F: include/linux/sframe.h
> F: include/linux/unwind*.h
> F: kernel/unwind/
Good catch! Should we rather add the following in the series you are
basing on, as there are already arch-specific unwind_user.h and
unwind_user_sframe.h?
F: arch/*/include/asm/unwind*.h
On the other hand I wonder whether the arch-specific headers should
remain maintained by the respective arch maintainers? How is that
handled in general?
> diff --git a/arch/Kconfig b/arch/Kconfig
> @@ -520,6 +520,13 @@ config SFRAME_VALIDATION
>
> If unsure, say N.
>
> +config ARCH_SUPPORTS_SFRAME_UNWINDER
> + bool
> + help
> + An architecture can select this if it enables the sframe (Simple
> + Frame) unwinder for unwinding kernel stack traces. It uses unwind
> + table that is directly generatedby toolchain based on DWARF CFI information.
Nit: s/sframe/SFrame/
> +
> config HAVE_PERF_REGS
> bool
> help
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> @@ -112,6 +112,7 @@ config ARM64
> select ARCH_SUPPORTS_SCHED_SMT
> select ARCH_SUPPORTS_SCHED_CLUSTER
> select ARCH_SUPPORTS_SCHED_MC
> + select ARCH_SUPPORTS_SFRAME_UNWINDER
> select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
> select ARCH_WANT_COMPAT_IPC_PARSE_VERSION if COMPAT
> select ARCH_WANT_DEFAULT_BPF_JIT
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> @@ -20,4 +20,17 @@ config ARM64_RELOC_TEST
> depends on m
> tristate "Relocation testing module"
>
> +config SFRAME_UNWINDER
Why do you introduce this for arm64 (and debug) only? If s390 were to
add support (as replacement for s390 backchain), this would have to be
moved or duplicated. It would not suffice to enable
ARCH_SUPPORTS_SFRAME_UNWINDER to also enable SFRAME_UNWINDER.
As mentioned in my feedback on the previous patch in this series:
Would it make sense to align the naming to the existing
HAVE_UNWIND_USER_SFRAME, for instance:
HAVE_UNWIND_KERNEL_SFRAME
> + bool "Sframe unwinder"
> + depends on AS_SFRAME3
> + depends on 64BIT
> + depends on ARCH_SUPPORTS_SFRAME_UNWINDER
> + select SFRAME_LOOKUP
> + help
> + This option enables the sframe (Simple Frame) unwinder for unwinding
> + kernel stack traces. It uses unwind table that is directly generated
> + by toolchain based on DWARF CFI information. In, practice this can
> + provide more reliable stacktrace results than unwinding with frame
> + pointers alone.
Nit: s/sframe/SFrame/
> +
> source "drivers/hwtracing/coresight/Kconfig"
You are introducing two new Kconfig options (SFRAME_UNWINDER and
ARCH_SUPPORTS_SFRAME_UNWINDER). I wonder whether they could somehow be
combined into a single new option. Although I am not sure how an option
can be both selectable and depending at the same time, so that the ARM64
config could select it, but it would also depend on the above.
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> @@ -491,6 +491,8 @@
> *(.rodata1) \
> } \
> \
> + SFRAME \
> + \
> /* PCI quirks */ \
> .pci_fixup : AT(ADDR(.pci_fixup) - LOAD_OFFSET) { \
> BOUNDED_SECTION_PRE_LABEL(.pci_fixup_early, _pci_fixups_early, __start, __end) \
> @@ -911,6 +913,19 @@
> #define TRACEDATA
> #endif
>
> +#ifdef CONFIG_SFRAME_UNWINDER
> +#define SFRAME \
> + /* sframe */ \
> + .sframe : AT(ADDR(.sframe) - LOAD_OFFSET) { \
> + __start_sframe_header = .; \
__start_sframe[_section] = .;
> + KEEP(*(.sframe)) \
> + KEEP(*(.init.sframe)) \
> + __stop_sframe_header = .; \
__stop_sframe[_section] = .;
Unless I am missing something both are not the start/stop of the .sframe
header (in the .sframe section) but the .sframe section itself (see also
your subsequent "[PATCH v3 4/8] sframe: Provide PC lookup for vmlinux
.sframe section." where you assign both to kernel_sfsec.sframe_start
and kernel_sfsec.sframe_end.
> + }
> +#else
> +#define SFRAME
> +#endif
> +
> #ifdef CONFIG_PRINTK_INDEX
> #define PRINTK_INDEX \
> .printk_index : AT(ADDR(.printk_index) - LOAD_OFFSET) { \
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:44 UTC|newest]
Thread overview: 13+ 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
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 [this message]
2026-04-06 18:49 ` [PATCH v3 3/8] arm64: entry: add unwind info for various kernel entries Dylan Hatch
2026-04-06 18:49 ` [PATCH v3 4/8] sframe: Provide PC lookup for vmlinux .sframe section Dylan Hatch
2026-04-06 18:49 ` [PATCH v3 5/8] sframe: Allow unsorted FDEs Dylan Hatch
2026-04-06 18:49 ` [PATCH v3 6/8] arm64/module, sframe: Add sframe support for modules Dylan Hatch
2026-04-06 18:49 ` [PATCH v3 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION Dylan Hatch
2026-04-06 18:50 ` [PATCH v3 8/8] unwind: arm64: Use sframe to unwind interrupt frames Dylan Hatch
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=cc7f741c-41a0-4620-b5d5-3428aaa7648f@linux.ibm.com \
--to=jremus@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=dylanbhatch@google.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iii@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox