linux-kernel - Re: [PATCH v3 1/6] x86/sme: Use percpu boolean to control wbinvd during kexec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <96c39744eacd6d670b1559268137d56c381d84ab.camel@intel.com>
Date: Fri, 27 Jun 2025 01:06:44 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, "bp@...en8.de" <bp@...en8.de>,
	"peterz@...radead.org" <peterz@...radead.org>, "hpa@...or.com"
	<hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>,
	"thomas.lendacky@....com" <thomas.lendacky@....com>, "tglx@...utronix.de"
	<tglx@...utronix.de>
CC: "seanjc@...gle.com" <seanjc@...gle.com>, "x86@...nel.org"
	<x86@...nel.org>, "sagis@...gle.com" <sagis@...gle.com>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kirill.shutemov@...ux.intel.com"
	<kirill.shutemov@...ux.intel.com>, "Williams, Dan J"
	<dan.j.williams@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "ashish.kalra@....com" <ashish.kalra@....com>,
	"nik.borisov@...e.com" <nik.borisov@...e.com>
Subject: Re: [PATCH v3 1/6] x86/sme: Use percpu boolean to control wbinvd
 during kexec

On Fri, 2025-06-27 at 00:39 +0000, Edgecombe, Rick P wrote:
> On Fri, 2025-06-27 at 00:37 +0000, Huang, Kai wrote:
> > > Arguably the supported/enabled part could be moved to a separate earlier
> > > patch.
> > > The code change would just get immediately replaced, but the benefit would
> > > be
> > > that a bisect would show which part of the change was responsible.
> > 
> > I am not a fan of splitting the new variable and the user into different
> > patches, as long as the patch isn't too big to review.  You need to review
> > them together anyway I think, so arguably putting them together is easier to
> > review.
> 
> How about if Tom thinks there is any risk, we can split them for bisectability
> help. Otherwise reduce the churn.

Sure.  But I don't understand how this can impact bisect?

Let's assume we have patch 1 to introduce the boolean w/o user, and patch 2
to modify SME code.  If there's any issue, the bisect will point to the
patch 2.  If we have one patch then the bisect will point to this one patch
too.  Is there any difference?

The downside of splitting into two patches is we need to make sure there's
no build warning when introducing a variable w/o user, for which we might
need to do additional things (e.g., it happens when adding a static function
w/o use).