From: Sean Christopherson <seanjc@google.com>
To: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: do not shadow apic global definition
Date: Tue, 2 Aug 2022 20:12:48 +0000 [thread overview]
Message-ID: <YumFQOeSGnRoqEkM@google.com> (raw)
In-Reply-To: <CAMZ6RqJUtFDKZj9Wo8EjG3nefwM3RztW00FRwXct-KgFo-HSLw@mail.gmail.com>
On Sat, Jul 30, 2022, Vincent MAILHOL wrote:
> On Sat. 30 Jul. 2022 at 02:48, Sean Christopherson <seanjc@google.com> wrote:
> > On Fri, Jul 29, 2022, Vincent Mailhol wrote:
> > > arch/x86/include/asm/apic.h declares a global variable named `apic'.
> > >
> > > Many function arguments from arch/x86/kvm/lapic.h also uses the same
> > > name and thus shadow the global declaration. For each case of
> > > shadowing, rename the function argument from `apic' to `lapic'.
> > >
> > > This patch silences below -Wshadow warnings:
> >
> > This is just the tip of the iceberg, nearly every KVM x86 .c file has at least one
> > "apic" variable. arch/x86/kvm/lapic.c alone has nearly 100. If this were the very
> > last step before a kernel-wide (or even KVM-wide) enabling of -Wshadow then maybe
> > it would be worth doing, but as it stands IMO it's unnecesary churn.
>
> I would say the opposite: in terms of *volume*, warnings from apic.c
> would be the tip of the iceberg and apic.h is the submerged part.
>
> When the warning occurs in a header from the include directory, it
> will spam some random files which include such header. This is
> annoying when trying to triage W=2 warnings because you get totally
> unrelated warning (and W=2 has some useful flags such as
> -Wmaybe-uninitialized so there are some insensitive to check it).
>
> My intent is only to silence the headers. I do not really care about
> the -Wshadow on *.c files because it is local.
But lapic.h is a KVM-internal header, if you only care about reducing the number
of warnings and not actually "fixing" KVM, then why not suppress or filter the
warnings when building KVM?
prev parent reply other threads:[~2022-08-02 20:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 8:45 [PATCH] KVM: x86: do not shadow apic global definition Vincent Mailhol
2022-07-29 17:48 ` Sean Christopherson
2022-07-30 4:15 ` Vincent MAILHOL
2022-08-02 20:12 ` Sean Christopherson [this message]
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=YumFQOeSGnRoqEkM@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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