Linux Trace Kernel
 help / color / mirror / Atom feed
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


      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