Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Date:   Mon, 11 Dec 2023 18:21:40 -0800
In-Reply-To: <b028a431-92e0-4440-adf9-6b855edb88c0@suse.com>
Mime-Version: 1.0
References: <20231030141728.1406118-1-nik.borisov@suse.com>
 <ZT_UtjWSKCwgBxb_@google.com> <b028a431-92e0-4440-adf9-6b855edb88c0@suse.com>
Message-ID: <ZXfDtIful3mjgPTA@google.com>
Subject: Re: [PATCH] KVM: x86: User mutex guards to eliminate __kvm_x86_vendor_init()
From:   Sean Christopherson <seanjc@google.com>
To:     Nikolay Borisov <nik.borisov@suse.com>
Cc:     pbonzini@redhat.com, x86@kernel.org, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sat, Dec 09, 2023, Nikolay Borisov wrote:
>=20
>=20
> On 30.10.23 =D0=B3. 18:07 =D1=87., Sean Christopherson wrote:
> > On Mon, Oct 30, 2023, Nikolay Borisov wrote:
> > > Current separation between (__){0,1}kvm_x86_vendor_init() is
> > > superfluos as
> >=20
> > superfluous
> >=20
> > But this intro is actively misleading.=C2=A0 The double-underscore vari=
ant
> > most definitely
> > isn't superfluous, e.g. it eliminates the need for gotos reduces the
> > probability
> > of incorrect error codes, bugs in the error handling, etc.=C2=A0 It _be=
comes_
> > superflous
> > after switching to guard(mutex).
> >=20
> > IMO, this is one of the instances where the then solution problem
> > appoach is
> > counter-productive.=C2=A0 If there are no objections, I'll massage the =
change
> > log to
> > the below when applying (for 6.8, in a few weeks).
> >=20
> >  =C2=A0Use the recently introduced guard(mutex) infrastructure acquire =
and
> >  =C2=A0automatically release vendor_module_lock when the guard goes out=
 of
> > scope.
> >  =C2=A0Drop the inner __kvm_x86_vendor_init(), its sole purpose was to =
simplify
> >  =C2=A0releasing vendor_module_lock in error paths.
> >=20
> >  =C2=A0No functional change intended.
> >=20
> > > the the underscore version doesn't have any other callers.
> > >=20
>=20
>=20
> Has this fallen through the cracks as I don't see it in 6.7?

As above, I have this tagged for inclusion in 6.8, not 6.7.  Though admitte=
dly,
this one did actually fall through the cracks as I moved it to the wrong ma=
ilbox
when Paolo usurped the thread for unrelated guest_memfd stuff.  Anyways, I =
do
plan on grabbing this for 6.8, I'm just buried in non-upstream stuff right =
now.