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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).