linux-kernel - Re: [RFC PATCH 4/5] unwind: Rename unwind_stacktrace to unwind_user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250710173257.794d466d@batman.local.home>
Date: Thu, 10 Jul 2025 17:32:57 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: linux-kernel@...r.kernel.org, Josh Poimboeuf <jpoimboe@...nel.org>,
 Masami Hiramatsu <mhiramat@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Jiri Olsa
 <jolsa@...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>, Jens Remus <jremus@...ux.ibm.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton
 <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 4/5] unwind: Rename unwind_stacktrace to
 unwind_user_stacktrace

On Wed, 9 Jul 2025 17:41:39 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Wed,  9 Jul 2025 17:25:51 -0400
> Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> 
> > Rename the unwind_stacktrace structure to unwind_user_stacktrace to make
> > it consistent with the rest of the API.  
> 
> We originally had that name, but decided it was too long. As only the
> deferred unwind uses "unwind_" and it is currently only for user space, do
> we really need to have a 22 character structure name? 17 is already big
> enough.
> 
> And say we make an unwind_kernel_stacktrace()? I doubt we ever would, but
> if we did, it would still use the same structure. There's nothing
> inherently user space here (with maybe the exception of the compat type,
> but still).
> 
> And how is this unique to user space? The kernel can have sframes too.
> 
> Actually, I think we should rename "enum unwind_user_type" to
> "enum unwind_type".
> 
> struct unwind_entry {
> 	enum unwind_type	type;
> 	unsigned long		ip;
> };
> 
> As it is only being used for user space now, but it doesn't mean it can't
> be used for the kernel.
> 
> Heck, there's already work to use sframes in kernel code to replace ORC so
> that architectures like ARM64 can have live kernel patching.

Actually, I'm going to leave everything as is. The "struct unwind_user_*"
is only used internally in the user code and is not part of the API of
the infrastructure. The "struct unwind_stackframe" is used in the API
as a parameter. To me, it makes more sense to keep it short than adding
"user" to it and making all the callbacks have a longer name.

I know your patch 5 exposes more, but we'll deal with that when the
time comes.

-- Steve