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] [day] [month] [year] [list]

Message-ID: <b7xcrqkx4ouye4ayqkkvmpoirpqydhf663uim63w7nt3xwbgyc@kytyca6dgztu>
Date: Wed, 5 Nov 2025 09:06:36 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Borislav Petkov <bp@...en8.de>
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 12:03:18PM +0100, Borislav Petkov wrote:
> On Tue, Nov 04, 2025 at 06:29:20PM -0800, Josh Poimboeuf wrote:
> > Separate functions allows each reset function to stay close to its
> > select/update/apply counterparts.  That makes it easier to tell that
> > it's undoing all the right things.  Plus it preserves the existing
> > logical code layout/separation between mitigations.
> 
> ... with a forward declaration for each one?

Nope, these patches don't add any forward declarations because they
sanely put the caller below the callees.

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

> Because we don't have enough functions in this file already?

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?

> And even if the code structure is begging for
> us to turn it a OOO design, we're not doing it?

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 ;-)

-- 
Josh