From: Mark Rutland <mark.rutland@arm.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Gavin Shan <gshan@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>,
James Morse <james.morse@arm.com>,
linux-arm-kernel@lists.infradead.org,
Dmitry Safonov <0x7f454c46@gmail.com>,
Amit Daniel Kachhap <amit.kachhap@arm.com>,
Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH 4/4] arm64: traps: fix -Woverride-init warnings
Date: Mon, 26 Oct 2020 16:23:14 +0000 [thread overview]
Message-ID: <20201026162314.GA42396@C02TD0UTHF1T.local> (raw)
In-Reply-To: <20201026160342.3705327-4-arnd@kernel.org>
Hi Arnd,
On Mon, Oct 26, 2020 at 05:03:31PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> There are many warnings in this file when we re-enable the
> Woverride-init flag:
>
> arch/arm64/kernel/traps.c:704:26: warning: initialized field overwritten [-Woverride-init]
> 704 | [ESR_ELx_EC_UNKNOWN] = "Unknown/Uncategorized",
> | ^~~~~~~~~~~~~~~~~~~~~~~
> arch/arm64/kernel/traps.c:704:26: note: (near initialization for 'esr_class_str[0]')
> arch/arm64/kernel/traps.c:705:22: warning: initialized field overwritten [-Woverride-init]
> 705 | [ESR_ELx_EC_WFx] = "WFI/WFE",
> | ^~~~~~~~~
>
> This is harmless since they are only informational strings,
> but it's easy to change the code to ignore missing initialization
> and instead warn about possible duplicate initializers.
This has come up before, and IMO the warning is more hindrance than
helpful, given the prevalance of spurious warnings, and the (again IMO)
the rework needed to avoid those making the code harder to reason about.
We use this pattern all througout the kernel (e.g. in the syscall
wrappers), so unless the plan is to avoid this everywhere, I don't think
that we should alter individual cases. I also don't think that the Fixes
tag is appropriate given the code is correct.
Could we instead convince the compiler folk to give us better tools to
deal with this? For example, if we could annotate assignmments as
overridable or being an override, it'd be possible to distinguish the
benign cases from bad ones, without forcing us to have dynamic checks.
Thanks,
Mark.
>
> Fixes: 60a1f02c9e91 ("arm64: decode ESR_ELx.EC when reporting exceptions")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm64/kernel/traps.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 8af4e0e85736..d21cb25f9e1f 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -700,7 +700,6 @@ void do_sysinstr(unsigned int esr, struct pt_regs *regs)
> NOKPROBE_SYMBOL(do_sysinstr);
>
> static const char *esr_class_str[] = {
> - [0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
> [ESR_ELx_EC_UNKNOWN] = "Unknown/Uncategorized",
> [ESR_ELx_EC_WFx] = "WFI/WFE",
> [ESR_ELx_EC_CP15_32] = "CP15 MCR/MRC",
> @@ -746,7 +745,7 @@ static const char *esr_class_str[] = {
>
> const char *esr_get_class_string(u32 esr)
> {
> - return esr_class_str[ESR_ELx_EC(esr)];
> + return esr_class_str[ESR_ELx_EC(esr)] ?: "UNRECOGNIZED EC";
> }
>
> /*
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-26 16:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 16:03 [PATCH 1/4] arm64: cpu_errata: fix override-init warnings Arnd Bergmann
2020-10-26 16:03 ` [PATCH 2/4] arm64: hide more compat_vdso code Arnd Bergmann
2020-10-26 16:55 ` Mark Rutland
2020-10-29 13:35 ` Arnd Bergmann
2020-10-29 13:54 ` Dmitry Safonov
2020-10-26 16:03 ` [PATCH 3/4] arm64: avoid -Woverride-init warning Arnd Bergmann
2020-10-26 17:01 ` Mark Rutland
2020-10-26 19:30 ` Arnd Bergmann
2020-10-26 16:03 ` [PATCH 4/4] arm64: traps: fix -Woverride-init warnings Arnd Bergmann
2020-10-26 16:23 ` Mark Rutland [this message]
2020-10-26 16:31 ` Arnd Bergmann
2020-10-26 17:13 ` Peter Maydell
2020-10-26 17:27 ` Will Deacon
2020-10-26 19:28 ` Arnd Bergmann
2020-10-26 20:45 ` Will Deacon
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=20201026162314.GA42396@C02TD0UTHF1T.local \
--to=mark.rutland@arm.com \
--cc=0x7f454c46@gmail.com \
--cc=Dave.Martin@arm.com \
--cc=amit.kachhap@arm.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=peter.maydell@linaro.org \
--cc=will.deacon@arm.com \
--cc=will@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;
as well as URLs for NNTP newsgroup(s).