[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251009231437.GCaOhB3aeJlTCu_OkQ@fat_crate.local>
Date: Fri, 10 Oct 2025 01:14:37 +0200
From: Borislav Petkov <bp@...en8.de>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>,
Klaus Kusche <klaus.kusche@...puterix.info>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG
On Thu, Oct 09, 2025 at 06:13:20PM +0000, Kaplan, David wrote:
> If we really want to optimize a CONFIG_CPU_MITIGATIONS=n kernel, why not
> also look at alternatives that will never be enabled?
>
> All the extra NOPs I think can affect performance in various ways and if
> there was a way at compile time to know that the alternative would never be
> enabled (because the feature is completely dependent on a cpu mitigation)
> you could eliminate the NOPs...
I don't see why not. That mitigations gunk should be just like any other
CONFIG_-controllable item and not simply "leak" into the build because, oh
well, we've done it this way from the very beginning and no one should touch
it.
So yeah, eventually we should try this. I've been experimenting with
untangling bugs.c today, will check how much it actually saves us when
I finish beating the stinking pile into submission.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists