MIME-Version: 1.0
References: <20230301133841.18007-1-wei.w.wang@intel.com> <CALzav=eRYpnfg7bVQpVawAMraFdHu3OzqWr55Pg1SJC_Uh8t=Q@mail.gmail.com>
 <DS0PR11MB637348F1351260F8B7E97A15DCB29@DS0PR11MB6373.namprd11.prod.outlook.com>
 <ZAAsIBUuIIO1prZT@google.com> <DS0PR11MB6373DAA05CEF9AB8A83A6499DCB29@DS0PR11MB6373.namprd11.prod.outlook.com>
 <CAL715WLo90-JkJe6=GfX755t1jvaW-kqD_w++hv3Ed53fhLC3w@mail.gmail.com> <DS0PR11MB63735E9AC8F4636AF27DAA4ADCB39@DS0PR11MB6373.namprd11.prod.outlook.com>
In-Reply-To: <DS0PR11MB63735E9AC8F4636AF27DAA4ADCB39@DS0PR11MB6373.namprd11.prod.outlook.com>
From:   Mingwei Zhang <mizhang@google.com>
Date:   Thu, 2 Mar 2023 21:53:35 -0800
Message-ID: <CAL715WJsV3tPkMDK0exgHeuKOP9kJtc62Ra0jnRhT1Gd6AiEWg@mail.gmail.com>
Subject: Re: [PATCH v1] KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond
To:     "Wang, Wei W" <wei.w.wang@intel.com>
Cc:     David Matlack <dmatlack@google.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "Christopherson,, Sean" <seanjc@google.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Mar 2, 2023 at 5:50=E2=80=AFPM Wang, Wei W <wei.w.wang@intel.com> w=
rote:
>
> 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 =3D (cond);                                     \
> > > > +     int __ret =3D !!(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 B=
oolean?
> 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.
>
> > This is consistent with the original code which _is_ returning an integ=
er.
> >
> > > But I'm inclined to retain the original intention to have the macro
> > > return the value that was passed in:
> > > typeof(cond) __ret =3D (cond);
> >
> > hmm, I think it is appropriate to retain the original type of 'cond'
> > especially since it may also involve other arithmetic operations. But I=
 doubt it
> > will be very useful. For instance, who is going to write this code?
> >
>
> Maybe there is, maybe not. But it doesn=E2=80=99t hurt anything to leave =
the
> flexibility there using typeof(cond). As said, I'm also fine to use 'bool=
 ret',
> but probably not 'int' for no good reason.

Right, maybe or maybe not. But using typeof(cond) for the variable
does not always provide benefits. For instance if the 'cond' is
resolved as the 8-byte type like u64, we are wasting space at runtime.
We could have used a shorter type. In addition, throwing this to the
compiler creates complexity and sometimes bugs since the compiler
could have different behaviors.

So, I prefer not having typeof(cond) for KVM_BUG(). But if you have
strong opinions using typeof, go ahead.

Thanks.
-Mingwei