Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 23 Mar 2021 11:34:29 +0000
From:   Wei Liu <wei.liu@kernel.org>
To:     Ingo Molnar <mingo@kernel.org>
Cc:     Michael Kelley <mikelley@microsoft.com>,
        Xu Yihang <xuyihang@huawei.com>,
        KY Srinivasan <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
        "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "johnny.chenyi@huawei.com" <johnny.chenyi@huawei.com>,
        "heying24@huawei.com" <heying24@huawei.com>,
        Wei Liu <wei.liu@kernel.org>
Subject: Re: [PATCH -next] x86: Fix unused variable 'msr_val' warning
Message-ID: <20210323113429.zj64itbfpqkruval@liuwe-devbox-debian-v2>
References: <20210322031713.23853-1-xuyihang@huawei.com>
 <20210322210828.GA1961861@gmail.com>
 <MWHPR21MB15939242EA50C7C1728412D0D7659@MWHPR21MB1593.namprd21.prod.outlook.com>
 <20210323001303.GA3092649@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210323001303.GA3092649@gmail.com>
Precedence: bulk

On Tue, Mar 23, 2021 at 01:13:03AM +0100, Ingo Molnar wrote:
> 
> * Michael Kelley <mikelley@microsoft.com> wrote:
> 
> > From: Ingo Molnar <mingo.kernel.org@gmail.com> Sent: Monday, March 22, 2021 2:08 PM
> > > 
> > > * Xu Yihang <xuyihang@huawei.com> wrote:
> > > 
> > > > Fixes the following W=1 kernel build warning(s):
> > > > arch/x86/hyperv/hv_spinlock.c:28:16: warning: variable 'msr_val' set but not used [-
> > > Wunused-but-set-variable]
> > > >   unsigned long msr_val;
> > > >
> > > > As Hypervisor Top-Level Functional Specification states in chapter 7.5 Virtual Processor
> > > Idle Sleep State, "A partition which possesses the AccessGuestIdleMsr privilege (refer to
> > > section 4.2.2) may trigger entry into the virtual processor idle sleep state through a read to
> > > the hypervisor-defined MSR HV_X64_MSR_GUEST_IDLE". That means only a read is
> > > necessary, msr_val is not uesed, so __maybe_unused should be added.
> > > >
> > > > Reference:
> > > >
> > > > https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs
> > > >
> > > > Reported-by: Hulk Robot <hulkci@huawei.com>
> > > > Signed-off-by: Xu Yihang <xuyihang@huawei.com>
> > > > ---
> > > >  arch/x86/hyperv/hv_spinlock.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
> > > > index f3270c1fc48c..67bc15c7752a 100644
> > > > --- a/arch/x86/hyperv/hv_spinlock.c
> > > > +++ b/arch/x86/hyperv/hv_spinlock.c
> > > > @@ -25,7 +25,7 @@ static void hv_qlock_kick(int cpu)
> > > >
> > > >  static void hv_qlock_wait(u8 *byte, u8 val)
> > > >  {
> > > > -	unsigned long msr_val;
> > > > +	unsigned long msr_val __maybe_unused;
> > > >  	unsigned long flags;
> > > 
> > > Please don't add new __maybe_unused annotations to the x86 tree -
> > > improve the flow instead to help GCC recognize the initialization
> > > sequence better.
> > > 
> > > Thanks,
> > > 
> > > 	Ingo
> > 
> > Could you elaborate on the thinking here, or point to some written
> > discussion?   I'm just curious.   In this particular case, it's not a problem
> > with the flow or gcc detection.  This code really does read an MSR and
> > ignore that value that is read, so it's not clear how gcc would ever
> > figure out that's OK.
> 
> Yeah, so the canonical way to signal that the msr_val isn't used would 
> be to rewrite this as:
> 
> 
> 	if (READ_ONCE(*byte) == val) {
> 		unsigned long msr_val;
> 
> 		rdmsrl(HV_X64_MSR_GUEST_IDLE, msr_val);
> 
> 		(void)msr_val;
> 	}
> 
> (Also see the patch below - untested.)
> 
> This makes it abundantly clear that the rdmsr() msr_val return value 
> is not 'maybe' unused, but totally intentionally skipped.
> 
> Thanks,
> 
> 	Ingo
> 

Thank you for the advice, Ingo.

Wei.