Received-SPF: pass (google.com: domain of linux-kernel+bounces-22141-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 10 Jan 2024 03:55:44 -0800
From: Breno Leitao <leitao@debian.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: jpoimboe@kernel.org, mingo@redhat.com, tglx@linutronix.de, bp@alien8.de,
	x86@kernel.org, leit@meta.com, linux-kernel@vger.kernel.org,
	pawan.kumar.gupta@linux.intel.com, bpf@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v6 00/13] x86/bugs: Add a separate config for each
 mitigation
Message-ID: <ZZ6FwMTRppSa2eOG@gmail.com>
References: <20231121160740.1249350-1-leitao@debian.org>
 <ZZ5p3vdnTtU5TeJe@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZZ5p3vdnTtU5TeJe@gmail.com>

On Wed, Jan 10, 2024 at 10:56:46AM +0100, Ingo Molnar wrote:
> 
> * Breno Leitao <leitao@debian.org> wrote:
> 
> > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated,
> > where some mitigations have entries in Kconfig, and they could be
> > modified, while others mitigations do not have Kconfig entries, and
> > could not be controlled at build time.
> > 
> > The fact of having a fine grained control can help in a few ways:
> > 
> > 1) Users can choose and pick only mitigations that are important for
> > their workloads.
> > 
> > 2) Users and developers can choose to disable mitigations that mangle
> > the assembly code generation, making it hard to read.
> > 
> > 3) Separate configs for just source code readability,
> > so that we see *which* butt-ugly piece of crap code is for what
> > reason.
> > 
> > Important to say, if a mitigation is disabled at compilation time, it
> > could be enabled at runtime using kernel command line arguments.
> > 
> > Discussion about this approach:
> > https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@mail.gmail.com/
> > and
> > https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/
> > 
> > In order to get the missing mitigations, some clean up was done.
> > 
> > 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig
> > entries.
> > 
> > 2) Adding the missing mitigations, so, the mitigations have entries in the
> > Kconfig that could be easily configure by the user.
> > 
> > With this patchset applied, all configs have an individual entry under
> > CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION.
> 
> Yeah, so:
> 
>  - I took this older series and updated it to current upstream, and made
>    sure all renames were fully done: there were two new Kconfig option
>    uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.)
> 
>  - I also widened the renames to comments and messages, which were not
>    always covered.
> 
>  - Then I took this cover letter and combined it with a more high level
>    description of the reasoning behind this series I wrote up, and added it
>    to patch #1. (see it below.)
> 
>  - Then I removed the changelog repetition from the other patches and just
>    referred them back to patch #1.
> 
>  - Then I stuck the resulting updated series into tip:x86/bugs, without the 
>    last 3 patches that modify behavior.

Thanks for your work. I am currently reviwing the tip branch and the
merge seems go so far.

Regarding the last 3 patches, what are the next steps?

Thank you!
Breno