[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<LV3PR12MB9265301AEA5D0EDB672DC7A594EEA@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Thu, 9 Oct 2025 18:13:20 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, Borislav Petkov
<bp@...en8.de>
CC: 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
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> Sent: Thursday, October 9, 2025 12:14 PM
> To: Borislav Petkov <bp@...en8.de>
> Cc: Josh Poimboeuf <jpoimboe@...nel.org>; Kaplan, David
> <David.Kaplan@....com>; 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; H . Peter Anvin
> <hpa@...or.com>; Klaus Kusche <klaus.kusche@...puterix.info>; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Oct 09, 2025 at 12:15:57PM +0200, Borislav Petkov wrote:
> > On Wed, Oct 08, 2025 at 11:04:32PM -0700, Pawan Gupta wrote:
> > > Thats a lot. OTOH, most of the bugs.c is __init code, do you think it is
> > > still problematic?
> >
> > What is wrong with aiming to not have dead code in the kernel if it can be
> > removed cleanly?
>
> Nothing wrong with that. There are certain things (like I mentioned
> earlier) that needs to be moved out of bugs.c.
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...
--David Kaplan
Powered by blists - more mailing lists