linux-kernel - Re: [PATCH] KVM: x86: User mutex guards to eliminate __kvm_x86_vendor

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: <146168ae-900d-4eee-9a47-a1ba2ea57aa6@redhat.com>
Date:   Mon, 30 Oct 2023 18:10:51 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        Nikolay Borisov <nik.borisov@...e.com>
Cc:     x86@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: User mutex guards to eliminate
 __kvm_x86_vendor_init()

On 10/30/23 17:07, Sean Christopherson wrote:
> On Mon, Oct 30, 2023, Nikolay Borisov wrote:
>> Current separation between (__){0,1}kvm_x86_vendor_init() is superfluos as
> 
> superfluous
> 
> But this intro is actively misleading.  The double-underscore variant 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.  It _becomes_ superflous
> after switching to guard(mutex).
> 
> IMO, this is one of the instances where the "problem, then solution" appoach is
> counter-productive.  If there are no objections, I'll massage the change log to
> the below when applying (for 6.8, in a few weeks).

I think this is a "Speak Now or Forever Rest in Peace" situation.  I'm 
going to wait a couple days more for reviews to come in, post a v14 
myself, and apply the series to kvm/next as soon as Linus merges the 6.7 
changes.  The series will be based on the 6.7 tags/for-linus, and when 
6.7-rc1 comes up, I'll do this to straighten the history:

	git checkout kvm/next
	git tag -s -f kvm-gmem HEAD
	git reset --hard v6.7-rc1
	git merge tags/kvm-gmem
	# fix conflict with Christian Brauner's VFS series
	git commit
	git push kvm

6.8 is not going to be out for four months, and I'm pretty sure that 
anything discovered within "a few weeks" can be applied on top, and the 
heaviness of a 35-patch series will outweigh any imperfections by a long 
margin).

(Full disclosure: this is _also_ because I want to apply this series to 
the RHEL kernel, and Red Hat has a high level of disdain for 
non-upstream patches.  But it's mostly because I want all dependencies 
to be able to move on and be developed on top of stock kvm/next).

Paolo