[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86h5zj9laj.wl-maz@kernel.org>
Date: Fri, 11 Jul 2025 09:36:04 +0100
From: Marc Zyngier <maz@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Oliver Upton <oliver.upton@...ux.dev>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Joey Gouly <joey.gouly@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Zenghui Yu <yuzenghui@...wei.com>,
Mark Brown <broonie@...nel.org>,
James Morse <james.morse@....com>,
Sebastian Ott <sebott@...hat.com>,
linux-arm-kernel@...ts.infradead.org,
kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: arm64: fix u64_replace_bits() usage
On Fri, 11 Jul 2025 08:27:47 +0100,
Arnd Bergmann <arnd@...nel.org> wrote:
>
> From: Arnd Bergmann <arnd@...db.de>
>
> u64_replace_bits() returns a modified word but does not actually modify
> its argument, as pointed out by this new warning:
>
> arch/arm64/kvm/sys_regs.c: In function 'access_mdcr':
> arch/arm64/kvm/sys_regs.c:2654:17: error: ignoring return value of 'u64_replace_bits' declared with attribute 'warn_unused_result' [-Werror=unused-result]
> 2654 | u64_replace_bits(val, hpmn, MDCR_EL2_HPMN);
>
> The intention here must have been to update 'val', so do that instead.
>
> Fixes: efff9dd2fee7 ("KVM: arm64: Handle out-of-bound write to MDCR_EL2.HPMN")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> 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 33aa4f5071b8..793fb19bebd6 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2651,7 +2651,7 @@ static bool access_mdcr(struct kvm_vcpu *vcpu,
> */
> if (hpmn > vcpu->kvm->arch.nr_pmu_counters) {
> hpmn = vcpu->kvm->arch.nr_pmu_counters;
> - u64_replace_bits(val, hpmn, MDCR_EL2_HPMN);
> + val = u64_replace_bits(val, hpmn, MDCR_EL2_HPMN);
> }
>
> __vcpu_assign_sys_reg(vcpu, MDCR_EL2, val);
This is only in -next, right? Because I have a fix for this already
queued for 6.16, as per [1].
Thanks,
M.
[1] https://lore.kernel.org/r/20250709093808.920284-2-ben.horgan@arm.com
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists