[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZpTtTQ-ysRGw2tZG@J2N7QTR9R3>
Date: Mon, 15 Jul 2024 10:35:09 +0100
From: Mark Rutland <mark.rutland@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: Sebastian Ott <sebott@...hat.com>, 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 Fri, Jul 12, 2024 at 10:55:16PM +0100, Marc Zyngier wrote:
> On Fri, 12 Jul 2024 12:03:30 +0100,
> Sebastian Ott <sebott@...hat.com> wrote:
> >
> > Remove double initializations in cases where that's easily possible
> > - like extra NULL initialization in static global structures. In the
> > other cases just silence -Woverride-init.
> >
> > To fix warnings like the following:
> > arch/arm64/kvm/hyp/vhe/switch.c:271:43: warning: initialized field overwritten [-Woverride-init]
> > 271 | [ESR_ELx_EC_CP15_32] = kvm_hyp_handle_cp15_32,
> > | ^~~~~~~~~~~~~~~~~~~~~~
> >
> > Signed-off-by: Sebastian Ott <sebott@...hat.com>
> > ---
> > arch/arm64/kvm/handle_exit.c | 5 +++++
> > arch/arm64/kvm/hyp/nvhe/switch.c | 6 ++----
> > arch/arm64/kvm/hyp/vhe/switch.c | 3 +--
> > arch/arm64/kvm/sys_regs.c | 5 +++++
> > 4 files changed, 13 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> > index d7c2990e7c9e..2c049746657c 100644
> > --- a/arch/arm64/kvm/handle_exit.c
> > +++ b/arch/arm64/kvm/handle_exit.c
> > @@ -291,6 +291,9 @@ static int handle_svc(struct kvm_vcpu *vcpu)
> > return 1;
> > }
> >
> > +__diag_push();
> > +__diag_ignore_all("-Woverride-init", "Allow field overrides in exit_handlers");
>
> The wording you are looking for is "Silence stupid warning". I really
> mean it. There is really nothing wrong with this code, and if the
> compiler doesn't understand the purpose of a default initialiser, then
> *maybe* it should be fixed rather than polluting the kernel with this
> stuff.
IMO this would be a lot more palatable if this were an attribute on the
struct or assignment, like we asked for in the past:
https://lore.kernel.org/lkml/20190809083251.GA48423@lakrids.cambridge.arm.com/
Having something that we could put specifically on the default assignment would
make this a lot more legible and better capture the intent.
Mark.
Powered by blists - more mailing lists