From: Ingo Molnar <mingo@kernel.org>
To: Michael Kelley <mikelley@microsoft.com>
Cc: 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>
Subject: Re: [PATCH -next] x86: Fix unused variable 'msr_val' warning
Date: Tue, 23 Mar 2021 01:13:03 +0100 [thread overview]
Message-ID: <20210323001303.GA3092649@gmail.com> (raw)
In-Reply-To: <MWHPR21MB15939242EA50C7C1728412D0D7659@MWHPR21MB1593.namprd21.prod.outlook.com>
* 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
arch/x86/hyperv/hv_spinlock.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index f3270c1fc48c..7d948513ed42 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -25,7 +25,6 @@ static void hv_qlock_kick(int cpu)
static void hv_qlock_wait(u8 *byte, u8 val)
{
- unsigned long msr_val;
unsigned long flags;
if (in_nmi())
@@ -48,8 +47,14 @@ static void hv_qlock_wait(u8 *byte, u8 val)
/*
* Only issue the rdmsrl() when the lock state has not changed.
*/
- if (READ_ONCE(*byte) == val)
+ if (READ_ONCE(*byte) == val) {
+ unsigned long msr_val;
+
rdmsrl(HV_X64_MSR_GUEST_IDLE, msr_val);
+
+ (void)msr_val;
+ }
+
local_irq_restore(flags);
}
next prev parent reply other threads:[~2021-03-23 0:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 3:17 [PATCH -next] x86: Fix unused variable 'msr_val' warning Xu Yihang
2021-03-22 11:04 ` Wei Liu
2021-03-22 21:08 ` Ingo Molnar
2021-03-22 23:32 ` Michael Kelley
2021-03-23 0:13 ` Ingo Molnar [this message]
2021-03-23 11:34 ` Wei Liu
2021-03-23 2:43 ` Xu Yihang
2021-03-24 11:28 ` Wei Liu
-- strict thread matches above, loose matches on Subject: below --
2021-03-18 8:03 Xu Yihang
2021-03-19 18:48 ` Michael Kelley
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=20210323001303.GA3092649@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=haiyangz@microsoft.com \
--cc=heying24@huawei.com \
--cc=johnny.chenyi@huawei.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=sthemmin@microsoft.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xuyihang@huawei.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.