Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ryan Roberts" <ryan.roberts@arm.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	robh@kernel.org, conor+dt@kernel.org,
	"Oliver Upton" <oupton@kernel.org>,
	"Marc Zyngier" <maz@kernel.org>
Subject: Re: [RFC PATCH v2 11/15] KVM: arm64: Export stage-2 MMU config
Date: Thu, 15 Oct 2026 14:43:55 +0000	[thread overview]
Message-ID: <sashiko-outbox-172975@kernel.org> (raw)
In-Reply-To: <20261015142552.4128028-12-ryan.roberts@arm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] cleanup: mixing goto-based cleanup and guard() in kvm_arch_get_guest_mmu()
--

commit 857dcf037db9acd0dfd4486a2d4b54b73644b090
Author: Jean-Philippe Brucker <jpb@kernel.org>

KVM: arm64: Export stage-2 MMU config

This commit provides an API to drivers that want to share the stage 2
configuration of a VM with their device. It introduces the
kvm_arch_get_guest_mmu and kvm_arch_put_guest_mmu functions to expose the
stage 2 MMU config of an EL1 VM.

> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 9ba86450fe4af..56490226f973b 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
[ ... ]
> +struct kvm_arch_guest_mmu *kvm_arch_get_guest_mmu(struct kvm *kvm)
> +{
> +	int ret;
> +	struct kvm_arch_guest_mmu *mmu;
> +
> +	guard(mutex)(&kvm->arch.config_lock);
> +
> +	if (is_protected_kvm_enabled())
> +		return ERR_PTR(-EOPNOTSUPP);
[ ... ]
> +	ret = kvm_arm_pinned_vmid_get(kvm);
> +	if (ret < 0)
> +		return ERR_PTR(ret);
> +
> +	ret = -ENOMEM;
> +	mmu = kzalloc_obj(*mmu, GFP_KERNEL_ACCOUNT);
> +	if (!mmu)
> +		goto err_unpin_vmid;
> +
> +	mmu->vtcr = kvm->arch.mmu.vtcr;
> +	mmu->vttbr = kvm_get_vttbr(&kvm->arch.mmu);
> +	mmu->hcr = kvm_mmu_get_hcr(kvm, 0);
> +
> +	return mmu;
> +
> +err_unpin_vmid:
> +	kvm_arm_pinned_vmid_put(kvm);
> +	return ERR_PTR(ret);
> +}

[Severity: Low]
Is it intentional to mix goto-based cleanup and guard macros in this function?

The function uses guard(mutex)(&kvm->arch.config_lock) for scope-based
locking, but also relies on the goto err_unpin_vmid label to clean up the
VMID when kzalloc_obj fails. 

According to the cleanup helpers guidelines, mixing goto-based error handling
with scope-based cleanup helpers in the same function creates confusing
ownership semantics and increases the risk of double-free or resource leak
bugs during future code edits.

Would it be better to convert this entirely to scope-based cleanup, or
alternatively, use manual unlocks without the guard macro?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015142552.4128028-1-ryan.roberts@arm.com?part=11

  reply	other threads:[~2026-10-15 14:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 14:25 [RFC PATCH v2 00/15] Arm Core Local Accelerator Driver Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 01/15] misc/arm-cla: Add driver skeleton and documentation Ryan Roberts
2026-10-15 14:35   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 02/15] misc/arm-cla: Add launch operation helpers Ryan Roberts
2026-10-15 14:42   ` sashiko-bot
2026-10-15 16:17   ` Greg Kroah-Hartman
2026-10-15 16:32     ` Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 03/15] dt-bindings: misc: Add Arm Core Local Accelerator Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 04/15] misc/arm-cla: Probe firmware-described devices Ryan Roberts
2026-10-15 14:37   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 05/15] misc/arm-cla: Initialize devices on CPU bringup Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 06/15] misc/arm-cla: Accelerator context save and restore Ryan Roberts
2026-10-15 14:41   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 07/15] misc/arm-cla: Set up memory translation context Ryan Roberts
2026-10-15 14:25 ` [RFC PATCH v2 08/15] misc/arm-cla: Manage domain contexts Ryan Roberts
2026-10-15 14:38   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 09/15] misc/arm-cla: Add userspace interface Ryan Roberts
2026-10-15 14:47   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 10/15] KVM: arm64: Introduce support to pin VMIDs Ryan Roberts
2026-10-15 14:38   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 11/15] KVM: arm64: Export stage-2 MMU config Ryan Roberts
2026-10-15 14:43   ` sashiko-bot [this message]
2026-10-15 14:25 ` [RFC PATCH v2 12/15] vfio: Support VFIO devices that access the CPU MMU Ryan Roberts
2026-10-15 14:44   ` sashiko-bot
2026-10-15 16:44   ` Jason Gunthorpe
2026-10-15 14:25 ` [RFC PATCH v2 13/15] misc/arm-cla: Add stage-2 MTC and VM context switch Ryan Roberts
2026-10-15 14:40   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 14/15] misc/arm-cla: Support exclusive context assignment Ryan Roberts
2026-10-15 14:41   ` sashiko-bot
2026-10-15 14:25 ` [RFC PATCH v2 15/15] misc/arm-cla: Add vfio-mdev user interface Ryan Roberts
2026-10-15 14:49   ` sashiko-bot
2026-10-15 16:41   ` Jason Gunthorpe

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=sashiko-outbox-172975@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=robh@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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