From: Sean Christopherson <seanjc@google.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: David Matlack <dmatlack@google.com>,
Mingwei Zhang <mizhang@google.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond
Date: Mon, 6 Mar 2023 12:34:13 -0800 [thread overview]
Message-ID: <ZAZM7z2O1vV5MZjn@google.com> (raw)
In-Reply-To: <DS0PR11MB6373C317B71C7B1BABB9BED2DCB09@DS0PR11MB6373.namprd11.prod.outlook.com>
On Sat, Mar 04, 2023, Wang, Wei W wrote:
> On Saturday, March 4, 2023 1:36 AM, David Matlack wrote:
> > > > On Friday, March 3, 2023 2:12 AM, Mingwei Zhang wrote:
> > > > > > On Thursday, March 2, 2023 12:55 PM, Mingwei Zhang wrote:
> > > > > > > I don't get it. Why bothering the type if we just do this?
> > > > > > >
> > > > > > > diff --git a/include/linux/kvm_host.h
> > > > > > > b/include/linux/kvm_host.h index 4f26b244f6d0..10455253c6ea
> > > > > > > 100644
> > > > > > > --- a/include/linux/kvm_host.h
> > > > > > > +++ b/include/linux/kvm_host.h
> > > > > > > @@ -848,7 +848,7 @@ static inline void kvm_vm_bugged(struct
> > > > > > > kvm
> > > > > > > *kvm)
> > > > > > >
> > > > > > > #define KVM_BUG(cond, kvm, fmt...) \
> > > > > > > ({ \
> > > > > > > - int __ret = (cond); \
> > > > > > > + int __ret = !!(cond); \
> > > > > >
> > > > > > This is essentially "bool __ret". No biggie to change it this way.
> > > > >
> > > > > !! will return an int, not a boolean, but it is used as a boolean.
> > > >
> > > > What's the point of defining it as an int when actually being used as a
> > Boolean?
> > > > Original returning of an 'int' is a bug in this sense. Either
> > > > returning a Boolean or the same type (length) as cond is good way to me.
> > >
> > > What's the point of using an integer? I think we need to ask the
> > > original author. But I think one of the reasons might be convenience
> > > as the return value. I am not sure if we can return a boolean in the
> > > function. But it should be fine here since it is a macro.
> > >
> > > Anyway, returning an 'int' is not a bug. The bug is the casting from
> > > 'cond' to the integer that may lose information and this is what you
> > > have captured.
> >
> > typeof() won't work if cond is a bitfield. See commit 8d4fbcfbe0a4 ("Fix
> > WARN_ON() on bitfield ops") from Linus from back in 2007:
>
> Yes, this seems to be a good reason for not going for typeof. Thanks for sharing.
Ya, just make __ret a bool. I'm 99% certain I just loosely copied from WARN_ON(),
but missed the !!.
next prev parent reply other threads:[~2023-03-06 20:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 13:38 [PATCH v1] KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond Wei Wang
2023-03-01 18:30 ` Mingwei Zhang
2023-03-01 19:47 ` David Matlack
2023-03-02 2:00 ` Wang, Wei W
2023-03-02 4:54 ` Mingwei Zhang
2023-03-02 10:26 ` Wang, Wei W
2023-03-02 18:12 ` Mingwei Zhang
2023-03-03 1:49 ` Wang, Wei W
2023-03-03 5:53 ` Mingwei Zhang
2023-03-03 17:36 ` David Matlack
2023-03-04 4:25 ` Wang, Wei W
2023-03-06 20:34 ` Sean Christopherson [this message]
2023-03-02 1:17 ` Isaku Yamahata
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=ZAZM7z2O1vV5MZjn@google.com \
--to=seanjc@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.