[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DS0PR11MB6373DAA05CEF9AB8A83A6499DCB29@DS0PR11MB6373.namprd11.prod.outlook.com>
Date: Thu, 2 Mar 2023 10:26:45 +0000
From: "Wang, Wei W" <wei.w.wang@...el.com>
To: Mingwei Zhang <mizhang@...gle.com>
CC: David Matlack <dmatlack@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v1] KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond
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.
But I'm inclined to retain the original intention to have the macro return
the value that was passed in:
typeof(cond) __ret = (cond);
Let's what others vote for.
Powered by blists - more mailing lists