Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Thu, 12 Oct 2023 09:48:14 -0700
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
Message-ID: <20231012164814.oc3r3sovsfrldpop@treble>
References: <20231010103028.4192223-1-leitao@debian.org>
 <20231011044252.42bplzjsam3qsasz@treble>
 <20231011190317.GDZSbxdd5TuCIp5+JN@fat_crate.local>
 <20231011220325.5uje4xnfxuccumm7@treble>
 <20231012072920.GAZSegUJkwHbcernQo@fat_crate.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20231012072920.GAZSegUJkwHbcernQo@fat_crate.local>
Precedence: bulk

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