linux-kernel - Re: [RFC PATCH 05/56] x86/bugs: Reset spectre

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: <20251105200447.GBaQut3w4dLilZrX-z@fat_crate.local>
Date: Wed, 5 Nov 2025 21:04:47 +0100
From: Borislav Petkov <bp@...en8.de>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: "Kaplan, David" <David.Kaplan@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"H . Peter Anvin" <hpa@...or.com>, Alexander Graf <graf@...zon.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 05/56] x86/bugs: Reset spectre_v2 mitigations

On Wed, Nov 05, 2025 at 09:06:36AM -0800, Josh Poimboeuf wrote:
> Nope, these patches don't add any forward declarations because they
> sanely put the caller below the callees.

Not happy about the added ifdeffery tho. I guess we can move it inside the
functions themselves or mark them __maybe_unused - whatever makes the
compilers not complain.

> We should put cpu_select_mitigations() at the bottom too, then all those
> existing forward declarations can go away.

That's a good idea. We should, if it doesn't get too hairy.

> I don't see how the solution to "too many functions" is to start
> squirreling away some arbitrary parts of (otherwise logically separated)
> code in a hidden uber-function away from the rest?

I aim for this file to "keep it as simple as possible and leave enough
breadcrumbs as possible for later."

But your argument about keeping all the mitigations and their functions
together has some merit too.

Maybe we should do

arch/x86/kernel/cpu/bugs/mtg_<bla>.c
arch/x86/kernel/cpu/bugs/mtg_<foo>.c

:-P
 
> If "functions bad" then why not make cpu_select_mitigations() one big
> happy function with a ton of comments?  Just think of all the function
> savings ;-)

If it makes it more readable, always. But I see your point.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette