linux-kernel - Re: [PATCH v11 14/14] unwind_user/x86: Enable compat mode frame pointer unwinding on x86

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: <CAHk-=wiXsMA3OJ0tnSWFDwqH=H8OAsUwF2hqCuQ6uHaLmpQubg@mail.gmail.com>
Date: Fri, 27 Jun 2025 09:23:14 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org, x86@...nel.org, 
	Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.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>, Andrew Morton <akpm@...ux-foundation.org>, 
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH v11 14/14] unwind_user/x86: Enable compat mode frame
 pointer unwinding on x86

On Fri, 27 Jun 2025 at 07:01, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> That's not a function. It's just setting a macro named arch_unwind_user_next to
> be arch_unwind_user_next. I think adding "()" to the end of that will be
> confusing.

Yeah, we use the pattern

   #define abc abc

just to show "I have my own architecture-specific implementation for
this" without having to make up a *new* name for it.

[ We used to have things like "#define __arch_has_abc" instead, which
is just annoying particularly when people didn't even always agree on
the exact prefix. We still do, but we used to too. These days that
"this arch has" pattern is _mostly_ confined to config variables, I
think. ]

Adding parenthesis not only makes that much more complicated - now you
need to match argument numbers etc - but can actually end up causing
real issues where you now can't use that 'abc' as a function pointer
any more.

That said, parenthesis can also actually help catch mis-uses (ie maybe
you *cannot* use the function as a function pointer, exactly because
some architectures _only_ implement it as a macro), so it's not like
parentheses are necessarily always wrong, but in general, I think that

  #define abc abc

pattern is the simplest and best way for an architecture header file
to say "I have an implementation for this".

And obviously the reason we have to use macros for this is because C
doesn't have a way to test for symbols existing. Other languages do
have things like that (various levels of "reflection"), but in C
you're basically limited to the pre-processor.

             Linus