From: Sean Christopherson <seanjc@google.com>
To: Michal Luczaj <mhal@rbox.co>
Cc: dmatlack@google.com, mizhang@google.com,
isaku.yamahata@gmail.com, pbonzini@redhat.com,
Wei Wang <wei.w.wang@intel.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond
Date: Fri, 2 Jun 2023 09:56:52 -0700 [thread overview]
Message-ID: <ZHofVKJxjaUxIDUN@google.com> (raw)
In-Reply-To: <8f319a1e-a869-b666-b606-c0b4764ef7b1@rbox.co>
On Fri, Jun 02, 2023, Michal Luczaj wrote:
> On 6/2/23 03:20, Sean Christopherson wrote:
> > On Tue, 07 Mar 2023 21:52:33 +0800, Wei Wang wrote:
> >> Current KVM_BUG and KVM_BUG_ON assume that 'cond' passed from callers is
> >> 32-bit as it casts 'cond' to the type of int. This will be wrong if 'cond'
> >> provided by a caller is 64-bit, e.g. an error code of 0xc0000d0300000000
> >> will be converted to 0, which is not expected.
> >>
> >> Improves the implementation by using bool in KVM_BUG and KVM_BUG_ON.
> >> 'bool' is preferred to 'int' as __ret is essentially used as a boolean
> >> and coding-stytle.rst documents that use of bool is encouraged to improve
> >> readability and is often a better option than 'int' for storing boolean
> >> values.
> >>
> >> [...]
> >
> > Applied to kvm-x86 generic, thanks!
> >
> > [1/1] KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond
> > https://github.com/kvm-x86/linux/commit/c9d601548603
>
> I guess this makes the !! in kvm_vm_ioctl_create_vcpu() unnecessary:
>
> KVM_BUG_ON(!!xa_store(&kvm->vcpu_array, vcpu->vcpu_idx, vcpu, 0)...
Ya, I saw that, which in addition to Wei's ping, is what reminded me that the
KVM_BUG_ON() fix hadn't been merged.
> Is it worth a patch (perhaps along with chopping off !! in
> kvm_msr_allowed() and few other places)?
Yes, I think so.
next prev parent reply other threads:[~2023-06-02 16:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 13:52 [PATCH v2] KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond Wei Wang
2023-03-07 16:35 ` Mingwei Zhang
2023-03-08 23:26 ` Sean Christopherson
2023-06-01 13:30 ` Wang, Wei W
2023-06-01 16:20 ` Sean Christopherson
2023-06-02 0:52 ` Wang, Wei W
2023-06-02 1:20 ` Sean Christopherson
2023-06-02 16:47 ` Michal Luczaj
2023-06-02 16:56 ` Sean Christopherson [this message]
2023-06-05 11:53 ` Michal Luczaj
2023-06-05 15:19 ` Sean Christopherson
2023-06-05 20:42 ` Michal Luczaj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZHofVKJxjaUxIDUN@google.com \
--to=seanjc@google.com \
--cc=dmatlack@google.com \
--cc=isaku.yamahata@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhal@rbox.co \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=wei.w.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox