linux-kernel - Re: [RFC][PATCH] ftrace: Make DYNAMIC_FTRACE always enabled for architectures that support it

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-=wjXjq7wJM-xnTCcGCxg2viUcN6JfHBETpvD94HX7HTHFQ@mail.gmail.com>
Date: Thu, 3 Jul 2025 09:57:37 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, 
	Linux trace kernel <linux-trace-kernel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Mark Rutland <mark.rutland@....com>, 
	Alexandre Ghiti <alex@...ti.fr>, ChenMiao <chenmiao.ku@...il.com>, linux-arch@...r.kernel.org
Subject: Re: [RFC][PATCH] ftrace: Make DYNAMIC_FTRACE always enabled for
 architectures that support it

On Thu, 3 Jul 2025 at 08:52, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Remove the prompt to pick DYNAMIC_FTRACE and simply enable it if the
> architecture supports it.

I don't disagree with removing pointless Kconfig options, but if we do
this, we should do it properly.

Because now we have that entirely pointless "HAVE_DYNAMIC_FTRACE*" set
of config options. Which with this patch would be just stupid and
extra indirection that makes things harder to see.

IOW, with this patch we'd have

 (a) architectures that support dynamic ftrace will do

        select HAVE_DYNAMIC_FTRACE
        select HAVE_DYNAMIC_FTRACE_WITH_REGS

     (or whatever combination)

and then

 (b) kernel/trace/Kconfig will just turn that into the proper
DYNAMIC_FTRACE_xyz macros

and when this no longer involves any questions, there is absolutely
*zero* reason I can see for that pointless indirection through another
config variables.

Yes, yes, there's still the "depends on FUNCTION_TRACER" that
technically is a "reason" for that indirection, but it seems to be a
reall ybad one.

IOW, I think that if we do this, we should just get rid of the
"HAVE_DYNAMIC_FTRACE{_XYZ}" config variables entirely, and just make
architectures say

        select DYNAMIC_FTRACE if FUNCTION_TRACER

because the "HAVE_xyz" config variables seem to add no actual value,
only confusion.

Or am I missing some reason for still having that extra config
variable indirection?

             Linus