From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Breno Leitao <leitao@debian.org>,
tglx@linutronix.de, Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
leit@meta.com,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] x86/bugs: Add a separate config for each mitigation
Date: Thu, 12 Oct 2023 09:48:14 -0700 [thread overview]
Message-ID: <20231012164814.oc3r3sovsfrldpop@treble> (raw)
In-Reply-To: <20231012072920.GAZSegUJkwHbcernQo@fat_crate.local>
On Thu, Oct 12, 2023 at 09:29:20AM +0200, Borislav Petkov wrote:
> On Wed, Oct 11, 2023 at 03:03:25PM -0700, Josh Poimboeuf wrote:
> > I wouldn't call it senseless churn. There are concrete benefits -- for
> > both users and developers -- of having all the mitigation config options
> > living in the same config namespace.
>
> I don't see it. What does the same namespace give you? So you see in the
> code a bunch of ifdeffery and some or all of them have
> CONFIG_MITIGATION_ prepended. To me it doesn't matter whether they're
> mitigations or not - it is just the next Kconfig symbol.
It adds clarity by making the options more self-documenting.
For users who care about such things it makes it easier to identify
which options they need to enable or disable. And it makes it clearer
what those options do without having to go read the docs.
For developers it helps code readability: "ah, this nasty code is for a
side channel mitigation". Also it makes it easier to grep for.
> > Sure, the change might cause pain for users who disable these options,
> > but do those users actually exist?
>
> Apparently there are use cases where people simply want to disable all
> that mitigation crap because they want their performance back. This
> thread being one. And I know of another one with a similar sentiment.
Right, but we have a global option for that. I was wondering if anybody
actually uses the individual options (though I agree with Linus they
should exist to help with code readability).
--
Josh
next prev parent reply other threads:[~2023-10-12 16:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 10:30 Breno Leitao
2023-10-11 4:42 ` Josh Poimboeuf
2023-10-11 12:20 ` Breno Leitao
2023-10-11 16:49 ` Josh Poimboeuf
2023-10-11 19:03 ` Borislav Petkov
2023-10-11 22:03 ` Josh Poimboeuf
2023-10-12 7:29 ` Borislav Petkov
2023-10-12 16:48 ` Josh Poimboeuf [this message]
2023-10-15 15:06 ` Borislav Petkov
2023-10-16 10:07 ` Ingo Molnar
2023-10-16 12:46 ` Borislav Petkov
2023-10-17 15:08 ` Breno Leitao
2023-10-11 21:59 ` Ingo Molnar
2023-10-12 13:02 ` Breno Leitao
2023-10-12 17:05 ` Josh Poimboeuf
2023-10-12 18:51 ` Ingo Molnar
2023-10-12 20:43 ` Josh Poimboeuf
2023-10-13 10:50 ` Ingo Molnar
2023-10-15 14:11 ` Josh Poimboeuf
2023-10-16 9:45 ` Ingo Molnar
2023-10-17 17:15 ` Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231012164814.oc3r3sovsfrldpop@treble \
--to=jpoimboe@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=leit@meta.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®