Message-ID: <29c760a9-7dbf-4fe7-ad78-44c95bc00c4f@linux.ibm.com>
Date: Wed, 11 Feb 2026 17:15:40 +0100
From: Jens Remus <jremus@...ux.ibm.com>
To: Dylan Hatch <dylanbhatch@...gle.com>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
        bpf@...r.kernel.org, x86@...nel.org, linux-mm@...ck.org,
        Steven Rostedt <rostedt@...nel.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrii Nakryiko <andrii@...nel.org>,
        Indu Bhagat <indu.bhagat@...cle.com>,
        "Jose E. Marchesi" <jemarch@....org>,
        Beau Belgrave <beaub@...ux.microsoft.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Florian Weimer <fweimer@...hat.com>, Kees Cook <kees@...nel.org>,
        "Carlos O'Donell" <codonell@...hat.com>, Sam James <sam@...too.org>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        David Hildenbrand <david@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
        Michal Hocko
 <mhocko@...e.com>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [PATCH v13 00/18] unwind_deferred: Implement sframe handling

On 2/11/2026 2:47 AM, Dylan Hatch wrote:
> On Tue, Jan 27, 2026 at 7:06 AM Jens Remus <jremus@...ux.ibm.com> wrote:
>>
>> This is the implementation of parsing the SFrame V3 stack trace information
>> from an .sframe section in an ELF file.  It's a continuation of Josh's and
>> Steve's work that can be found here:
>>
>>    https://lore.kernel.org/all/cover.1737511963.git.jpoimboe@kernel.org/
>>    https://lore.kernel.org/all/20250827201548.448472904@kernel.org/
>>
>> Currently the only way to get a user space stack trace from a stack
>> walk (and not just copying large amount of user stack into the kernel
>> ring buffer) is to use frame pointers. This has a few issues. The biggest
>> one is that compiling frame pointers into every application and library
>> has been shown to cause performance overhead.
>>
>> Another issue is that the format of the frames may not always be consistent
>> between different compilers and some architectures (s390) has no defined
>> format to do a reliable stack walk. The only way to perform user space
>> profiling on these architectures is to copy the user stack into the kernel
>> buffer.
>>
>> SFrame [1] is now supported in binutils (x86-64, ARM64, and s390). There is
>> discussions going on about supporting SFrame in LLVM. SFrame acts more like
>> ORC, and lives in the ELF executable file as its own section. Like ORC it
>> has two tables where the first table is sorted by instruction pointers (IP)
>> and using the current IP and finding it's entry in the first table, it will
>> take you to the second table which will tell you where the return address
>> of the current function is located and then you can use that address to
>> look it up in the first table to find the return address of that function,
>> and so on. This performs a user space stack walk.
>>
>> Now because the .sframe section lives in the ELF file it needs to be faulted
>> into memory when it is used. This means that walking the user space stack
>> requires being in a faultable context. As profilers like perf request a stack
>> trace in interrupt or NMI context, it cannot do the walking when it is
>> requested. Instead it must be deferred until it is safe to fault in user
>> space. One place this is known to be safe is when the task is about to return
>> back to user space.
>>
>> This series makes the deferred unwind user code implement SFrame format V3
>> and enables it on x86-64.
>>
>> [1]: https://sourceware.org/binutils/wiki/sframe
>>
>>
>> This series applies on top of the tip perf/core branch:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  perf/core
>>
>> The to be stack-traced user space programs (and libraries) need to be
>> built with the recent SFrame stack trace information format V3, as
>> generated by the upcoming binutils 2.46 with assembler option --gsframe.
>> It can be built from source from the binutils-2_46-branch branch:
>>
>>   git://sourceware.org/git/binutils-gdb.git  binutils-2_46-branch

> Do you by chance have this work uploaded in a public branch somewhere?
> I'd like to get a new version of the SFrame for reliable stacktrace on
> arm64 patch series [1] working for SFrame V3, ideally with the SFrame
> library in your patch series here.
> 
> https://lore.kernel.org/lkml/20250904223850.884188-1-dylanbhatch@google.com/
No, I don't.  Following is how you can easily get to tip:perf/core with
this work applied using b4:

$ git checkout -b sframe v6.18
$ git pull --no-rebase git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core # pre-req for [PATCH v13 00/18] unwind_deferred: Implement sframe handling
$ b4 shazam -T 20260127150554.2760964-1-jremus@...ux.ibm.com # [PATCH v13 00/18] unwind_deferred: Implement sframe handling

Following is how you can get to a tervolds:master with all of the latest
sframe related series on top using b4:

$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master:sframe
$ git checkout sframe
$ b4 shazam -T 20260127150554.2760964-1-jremus@...ux.ibm.com # [PATCH v13 00/18] unwind_deferred: Implement sframe handling
$ git am -3 # resolve "unwind_user/sframe: Store .sframe section data in per-mm maple tree"
$ git am -3 # partially resolve "unwind_user/sframe: Add prctl() interface for registering .sframe sections"
$ git mergetool # manually resolve prctl.h and kernel/sys.c conflicts; bump PR_ADD_SFRAME and PR_REMOVE_SFRAME; each case must end with break;
$ git am --continue
$ b4 shazam -T 20260211141357.271402-1-jremus@...ux.ibm.com # optional [PATCH v9 0/6] x86/vdso: VDSO updates and fixes for sframes
$ b4 shazam -T 20260127151926.2805123-1-jremus@...ux.ibm.com # optional [PATCH v4 00/12] s390: SFrame user space unwinding
$ git am -3 # partially resolve "s390/vdso: Enable SFrame V3 generation in vDSO"
$ git mergetool # manually resolve arch/s390/kernel/vdso/Makefile conflict
$ git am --continue
$ git am -3 # resolve "s390/ptrace: Convert function macros to inline functions"

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@...ibm.com / jremus@...ux.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/

Powered by blists - more mailing lists