linux-kernel - Re: [PATCH 1/3] KVM: arm64: fix override-init warnings in W=1 builds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <875xt667n9.wl-maz@kernel.org>
Date: Mon, 15 Jul 2024 15:40:10 +0100
From: Marc Zyngier <maz@...nel.org>
To: Sebastian Ott <sebott@...hat.com>
Cc: linux-arm-kernel@...ts.infradead.org,
	kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Zenghui Yu <yuzenghui@...wei.com>
Subject: Re: [PATCH 1/3] KVM: arm64: fix override-init warnings in W=1 builds

On Mon, 15 Jul 2024 11:28:06 +0100,
Sebastian Ott <sebott@...hat.com> wrote:
> 
> On Fri, 12 Jul 2024, Marc Zyngier wrote:
> > On Fri, 12 Jul 2024 12:03:30 +0100,
> > Sebastian Ott <sebott@...hat.com> wrote:
> >> 
> >> -static const exit_handler_fn hyp_exit_handlers[] = {
> >> -	[0 ... ESR_ELx_EC_MAX]		= NULL,
> >> +static const exit_handler_fn hyp_exit_handlers[ESR_ELx_EC_MAX + 1] = {
> > 
> > Is this really any better? I don't think so. It makes the intent
> > disappear instead of making it explicit. Intent matters *a lot*.
> 
> I'm not claiming that it's an improvement to the code.

<rant>
Silencing pointless warnings should never have priority over keeping
the code maintainable and understandable. I hope we can agree we are
not in the business of making the kernel *worse* than it already is on
that front, right?
</rant>

I like good tooling as much as the next kernel tinkerer. But W=1 is,
in its current form, quite the opposite. Mark posted a link to a 5
year old thread, showing a number of ways compilers could use extra
annotation to lift the multiple initialisation ambiguity. This
approach has seen no traction, which is a bit sad.

> But yea, I see your point. How about disabling that flag in the
> makefile?

Yes, that'd be a reasonable workaround until someone fixes the
toolchains. I see that Loongarch is already doing it for the exact
same purpose.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.