[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86frek9182.wl-maz@kernel.org>
Date: Fri, 25 Jul 2025 08:30:21 +0100
From: Marc Zyngier <maz@...nel.org>
To: Justin Stitt <justinstitt@...gle.com>
Cc: James Morse <james.morse@....com>,
Alexandru Elisei <alexandru.elisei@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Oliver Upton <oliver.upton@...ux.dev>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Tom Rix <trix@...hat.com>,
linux-arm-kernel@...ts.infradead.org,
kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev,
stable@...r.kernel.org
Subject: Re: [PATCH 6.1.y] KVM: arm64: silence -Wuninitialized-const-pointer warning
[Dropping a few emails from the list, as they are very likely to
simply bounce]
On Fri, 25 Jul 2025 02:15:28 +0100,
Justin Stitt <justinstitt@...gle.com> wrote:
>
> A new warning in Clang 22 [1] complains that @clidr passed to
> get_clidr_el1() is an uninitialized const pointer. get_clidr_el1()
> doesn't really care since it casts away the const-ness anyways.
>
> Silence the warning by initializing the struct.
>
> This patch won't apply to anything past v6.1 as this code section was
> reworked in Commit 7af0c2534f4c ("KVM: arm64: Normalize cache configuration").
>
> Cc: stable@...r.kernel.org
> Fixes: 7c8c5e6a9101e ("arm64: KVM: system register handling")
No, this really doesn't fix anything other than paper over an
overzealous warning.
> Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d441f19b319e [1]
> Signed-off-by: Justin Stitt <justinstitt@...gle.com>
> ---
> arch/arm64/kvm/sys_regs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index f4a7c5abcbca..d7ebd7387221 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2948,7 +2948,7 @@ int kvm_sys_reg_table_init(void)
> {
> bool valid = true;
> unsigned int i;
> - struct sys_reg_desc clidr;
> + struct sys_reg_desc clidr = {0};
>
> /* Make sure tables are unique and in order. */
> valid &= check_sysreg_table(sys_reg_descs, ARRAY_SIZE(sys_reg_descs), false);
>
Frankly, this sort of things is the worse you can do, as
- it perpetuates a bad design
- it is completely pointless, as you pointed out
- it is only going to make it harder to backport other patches
The correct fix would be to backport the series described in
e8789ab7047a8, which should be easy enough to apply. it would also
make 6.1 less of a terrible kernel.
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists