From: Steven Rostedt <rostedt@kernel.org>
To: Jens Remus <jremus@linux.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrii Nakryiko <andrii@kernel.org>,
Indu Bhagat <indu.bhagat@oracle.com>,
"Jose E. Marchesi" <jemarch@gnu.org>,
Beau Belgrave <beaub@linux.microsoft.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Florian Weimer <fweimer@redhat.com>, Kees Cook <kees@kernel.org>,
"Carlos O'Donell" <codonell@redhat.com>,
Sam James <sam@gentoo.org>, Dylan Hatch <dylanbhatch@google.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Michal Hocko <mhocko@suse.com>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>
Subject: Re: [RFC][PATCH] unwind: Add stacktrace_setup system call
Date: Tue, 12 May 2026 12:47:33 -0400 [thread overview]
Message-ID: <20260512124733.57a38cb5@gandalf.local.home> (raw)
In-Reply-To: <43158d95-b4c2-44d2-a244-eb546fb2bfaa@linux.ibm.com>
On Fri, 8 May 2026 09:46:30 +0200
Jens Remus <jremus@linux.ibm.com> wrote:
> > STACKTRACE_REGISTER_SFRAME - This registers the sframe
> > STACKTRACE_UNREGISTER_SFRAME - This removes the sframe
> >
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>
> LGTM. Some comments/questions below.
Note, after talking with people at LSF/MM/BPF, I plan on completely
changing this system call into two distinct ones, and only for sframes.
I'll be sending that later this week.
>
> > diff --git a/include/uapi/linux/stacktrace.h b/include/uapi/linux/stacktrace.h
>
> > @@ -0,0 +1,10 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> > +#ifndef _UAPI_LINUX_STACKTRACE_H
> > +#define _UAPI_LINUX_STACKTRACE_H
> > +
> > +enum stacktrace_setup_types {
> > + STACKTRACE_REGISTER_SFRAME = 1,
> > + STACKTRACE_UNREGISTER_SFRAME = 2,
> > +};
> > +
> > +#endif /* _UAPI_LINUX_STACKTRACE_H */
>
> > diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
>
> Having the syscall live in kernel/unwind/sframe.c means it is only
> available if config option HAVE_UNWIND_USER_SFRAME is selected (which
> triggers sframe.o to be built and linked into the kernel), which makes
> sense as long as it only implements sframe-specific functionality.
> I suppose it could be moved elsewhere if non-sframe use cases would
> arise in the future?
The new system calls will only be for sframes. Other unwinders will need to
implement their own system calls.
>
> Would Dylan need to guard it when introducing HAVE_UNWIND_KERNEL_SFRAME?
> Provided the syscall fails with -ENOSYS if not implemented (e.g. when
> HAVE_UNWIND_USER_SFRAME is not enabled) the dummy implementations of
> sframe_add_section() and sframe_remove_section() in linux/sframe.h also
> return -ENOSYS, so the user observable behavior would be the same and
> it would not matter. Do you agree?
I'll reply to that when Dylan's patches get closer to acceptance ;-)
>
> > @@ -12,8 +12,10 @@
> > #include <linux/mm.h>
> > #include <linux/string_helpers.h>
> > #include <linux/sframe.h>
> > +#include <linux/syscalls.h>
> > #include <asm/unwind_user_sframe.h>
> > #include <linux/unwind_user_types.h>
> > +#include <uapi/linux/stacktrace.h>
> >
> > #include "sframe.h"
> > #include "sframe_debug.h"
> > @@ -838,3 +840,38 @@ void sframe_free_mm(struct mm_struct *mm)
> >
> > mtree_destroy(&mm->sframe_mt);
> > }
> > +
> > +/**
> > + * sys_stacktrace_setup - register an address for user space stacktrace walking.
> > + * @op: Type of operation to perform
> > + * @addr_start: The virtual address of the stacktrace information
> > + * @addr_length: The length of the stacktrace information
> > + * @text_start: The virtual address of the text that @addr_start represents
> > + * @text_length: The length of teh text
> > + *
> > + * This system call is used by dynamic library utilities to inform the kernel
> > + * of meta data that it loaded that can be used by the kernel to know how
> > + * to stack walk the given text locations.
> > + *
> > + * Currently only sframes are supported, but in the future, this may be used
> > + * to tell the kernel about JIT code which will most likely have a different
> > + * format.
> > + *
> > + * The type command may be extended and parameters may be used for other
> > + * purposes.
> > + *
> > + * Return: 0 if successful, otherwise a negative error.
> > + */
> > +SYSCALL_DEFINE5(stacktrace_setup, int, op, unsigned long, addr_start,
> > + unsigned long, addr_length, unsigned long, text_start,
> > + unsigned long, text_length)
>
> Would it make sense to keep the parameters generic from start, similar
> to how it is done in prctl()? Or can this be changed later, if the need
> arises?
With discussions at LSF/MM/BPF I'll have the system call parameters be a
pointer to a structure, and a size of that structure. All the API will then
be part of the structure.
Thanks for reviewing,
-- Steve
>
> SYSCALL_DEFINE5(stacktrace_setup, int, op, unsigned long, arg2,
> unsigned long, arg3, unsigned long, arg4, unsigned long, arg5)
>
> > +{
> > + switch (op) {
> > + case STACKTRACE_REGISTER_SFRAME:
> > + return sframe_add_section(addr_start, addr_start + addr_length,
> > + text_start, text_start+text_length);
>
> Nit:
> text_start, text_start + text_length);
>
> > + case STACKTRACE_UNREGISTER_SFRAME:
> > + return sframe_remove_section(addr_start);
> > + }
> > + return -EINVAL;
> > +}
> Thanks and regards,
> Jens
prev parent reply other threads:[~2026-05-12 16:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 15:43 [RFC][PATCH] unwind: Add stacktrace_setup system call Steven Rostedt
2026-04-29 15:47 ` Steven Rostedt
2026-04-29 18:32 ` Mathieu Desnoyers
2026-04-30 7:26 ` Geert Uytterhoeven
2026-04-29 18:42 ` Mathieu Desnoyers
2026-04-29 18:55 ` Steven Rostedt
2026-04-29 18:58 ` Steven Rostedt
2026-04-29 20:03 ` Steven Rostedt
2026-04-30 16:23 ` Jens Remus
2026-04-30 16:26 ` Mathieu Desnoyers
2026-04-30 17:33 ` Steven Rostedt
2026-04-30 17:38 ` Steven Rostedt
2026-05-07 12:37 ` Jose E. Marchesi
2026-05-08 1:57 ` Steven Rostedt
2026-05-08 7:32 ` Jose E. Marchesi
2026-05-08 7:46 ` Jens Remus
2026-05-12 16:47 ` Steven Rostedt [this message]
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=20260512124733.57a38cb5@gandalf.local.home \
--to=rostedt@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=beaub@linux.microsoft.com \
--cc=bp@alien8.de \
--cc=codonell@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dylanbhatch@google.com \
--cc=fweimer@redhat.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=indu.bhagat@oracle.com \
--cc=jemarch@gnu.org \
--cc=jolsa@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=jremus@linux.ibm.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=sam@gentoo.org \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/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