[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241217115039.GF11133@noisy.programming.kicks-ass.net>
Date: Tue, 17 Dec 2024 12:50:39 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Brendan Jackman <jackmanb@...gle.com>, Jonathan Corbet <corbet@....net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/bugs: Add force_cpu_bug= cmdline param
On Tue, Dec 17, 2024 at 12:17:52PM +0100, Borislav Petkov wrote:
> On Mon, Dec 16, 2024 at 06:58:24PM +0100, Brendan Jackman wrote:
> > OK yeah, tainting definitely makes sense, I think that goes quite a
> > long way to avoid bogus bug reports?
>
> It was my feeble attempt back then to leave enough breadcrumbs so that when
> I see a bug report, I can say: "well, then don't do that then" and mark it as
> invalid. :)
>
> > I will also update the docs to sound scarier.
>
> Right.
Perhaps issue a pr_warn() for every bit set? People tend to not like
WARN/ERR in their production logs much :-)
> > So do you think we should allow setting arbitrary cpu features? That
> > seems like a much bigger footgun. But then again, the difference
> > between "big footgun" and "very big footgun" is not that important,
> > either way it needs to be clear to users that this is a scary red
> > button.
>
> Yeah, with your patch we're half-way there. Might as well do the whole thing
> but again, this is only my opinion. Probably should hear what others have to
> say first...
Given I'm the one that did the retbleed=force thing (and other force
options), I'm in favour.
Powered by blists - more mailing lists