mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Fuad Tabba <fuad.tabba@linux.dev>
To: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>
Cc: Hyunwoo Kim <imv4bel@gmail.com>, Eric Auger <eauger@redhat.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	Sebastian Ene <sebastianene@google.com>,
	Fuad Tabba <tabba@google.com>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] KVM: arm64: vgic-its: Update GITS_CTLR.Enabled under its_lock
Date: Thu, 17 Sep 2026 17:20:20 +0100	[thread overview]
Message-ID: <20260917162020.1612577-1-fuad.tabba@linux.dev> (raw)

vgic_mmio_write_its_ctlr() clears its->enabled and invalidates the
translation cache under cmd_lock, but vgic_its_resolve_lpi() tests the
bit and populates the cache under its_lock. An injection that passed
the test before the disable can cache its translation after the
invalidation, and the cached path then injects from a disabled ITS.

Commit 13031fb6b835 ("KVM: arm64: vgic-its: Drop the translation cache
reference only for the erased entry") made the concurrent invalidations
safe but left this window open. The linked v2 closed it, and Oliver
withdrew his own diff there over a kvm->lock/vcpu->mutex inversion in
its vgic_its_invalidate_all_caches() hunk.

Take its_lock around the store and the invalidation, nested under
cmd_lock as the command handlers do. This is the v2's GITS_CTLR half,
widened to cover the store, and it has no such inversion.

Fixes: 8201d1028caa ("KVM: arm64: vgic-its: Maintain a translation cache per ITS")
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Link: https://lore.kernel.org/ah6Lsi4MfKUU6wBR@v4bel/
Cc: stable@vger.kernel.org
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---

Notes:
    Based on v7.3-rc3, applies cleanly to kvmarm/fixes.
    
    Picking up the fix Marc was worried had stalled [1]. Unlike the v2's
    GITS_CTLR hunk [2], the its->enabled store is inside the locked section
    too, so the enable test in vgic_its_resolve_lpi() is serialized by the
    lock rather than by store order.
    
    vgic_its_invalidate_all_caches(), the GICR_CTLR.EnableLPIs path, is
    left as is: it can take neither kvm->lock (it runs with vcpu->mutex
    held) nor config_lock (the userspace GICR_CTLR route already holds it).
    It belongs to the locking cleanup Oliver deferred as a long-term fix
    when he withdrew the v2 [3].
    
    [1] https://lore.kernel.org/861pbr6emw.wl-maz@kernel.org/
    [2] https://lore.kernel.org/ah6Lsi4MfKUU6wBR@v4bel/
    [3] https://lore.kernel.org/ah9KeH8bFl8NOveO@kernel.org/

 arch/arm64/kvm/vgic/vgic-its.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 9e782a4fea7e5..70b4acf1bf81d 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -1738,9 +1738,15 @@ static void vgic_mmio_write_its_ctlr(struct kvm *kvm, struct vgic_its *its,
 		 !(its->cbaser & GITS_CBASER_VALID)))
 		goto out;
 
+	/*
+	 * vgic_its_resolve_lpi() tests the enable bit and populates the
+	 * translation cache under its_lock.
+	 */
+	mutex_lock(&its->its_lock);
 	its->enabled = !!(val & GITS_CTLR_ENABLE);
 	if (!its->enabled)
 		vgic_its_invalidate_cache(its);
+	mutex_unlock(&its->its_lock);
 
 	/*
 	 * Try to process any pending commands. This function bails out early

base-commit: fd73f4a6659897191fa0d40695fe370925dd3780
-- 
2.39.5


                 reply	other threads:[~2026-09-17 16:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260917162020.1612577-1-fuad.tabba@linux.dev \
    --to=fuad.tabba@linux.dev \
    --cc=eauger@redhat.com \
    --cc=imv4bel@gmail.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sascha.bischoff@arm.com \
    --cc=sebastianene@google.com \
    --cc=seiden@linux.ibm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /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

all inboxes | Powered by JetHome®