From: Hyunwoo Kim <imv4bel@gmail.com>
To: maz@kernel.org, oupton@kernel.org, joey.gouly@arm.com,
seiden@linux.ibm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
kees@kernel.org
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
imv4bel@gmail.com
Subject: [PATCH v2] KVM: arm64: vgic-its: Serialize translation cache invalidation under its_lock
Date: Tue, 2 Jun 2026 16:52:18 +0900 [thread overview]
Message-ID: <ah6Lsi4MfKUU6wBR@v4bel> (raw)
vgic_its_invalidate_cache() walks the per-ITS translation cache with
xa_for_each() and drops the cache's reference on each entry with
vgic_put_irq().
It must be called with its_lock held. The ITS command handlers and the
ITS teardown path hold it, but two paths that also invalidate the cache do
not: the GITS_CTLR write path holds only cmd_lock, and the path that
clears EnableLPIs in a redistributor's GICR_CTLR holds neither lock. Two
contexts without a common lock, such as two vCPUs clearing EnableLPIs or
an EnableLPIs clear racing an ITS command, can drain the same cache at
once. If both observe an entry, erase it and then put it, the single
reference the cache holds on that entry is dropped more than once, and the
entry can be freed while an ITE still maps it.
Take its_lock in the two paths that lacked it: the GITS_CTLR write path
and vgic_its_invalidate_all_caches(), which clears EnableLPIs. Since
vgic_its_invalidate_all_caches() now takes a mutex, it can no longer walk
kvm->devices under rcu_read_lock(), so walk it under kvm->lock instead.
With its_lock held across every invalidation, each entry is erased and put
by a single context, so the cache reference is dropped exactly once.
Cc: stable@vger.kernel.org
Fixes: 8201d1028caa ("KVM: arm64: vgic-its: Maintain a translation cache per ITS")
Suggested-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
Changes in v2:
- Serialize the invalidation under its_lock as suggested by Oliver,
instead of v1's gating of the put on the xa_erase() return value.
- v1: https://lore.kernel.org/all/ah2c5lu4JbUg7dj-@v4bel/
---
arch/arm64/kvm/vgic/vgic-its.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 1d7e5d560af4..4bf60fa5bd7c 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -596,6 +596,8 @@ static void vgic_its_invalidate_cache(struct vgic_its *its)
struct vgic_irq *irq;
unsigned long idx;
+ lockdep_assert_held(&its->its_lock);
+
xa_for_each(&its->translation_cache, idx, irq) {
xa_erase(&its->translation_cache, idx);
vgic_put_irq(kvm, irq);
@@ -607,17 +609,16 @@ void vgic_its_invalidate_all_caches(struct kvm *kvm)
struct kvm_device *dev;
struct vgic_its *its;
- rcu_read_lock();
+ guard(mutex)(&kvm->lock);
- list_for_each_entry_rcu(dev, &kvm->devices, vm_node) {
+ list_for_each_entry(dev, &kvm->devices, vm_node) {
if (dev->ops != &kvm_arm_vgic_its_ops)
continue;
its = dev->private;
+ guard(mutex)(&its->its_lock);
vgic_its_invalidate_cache(its);
}
-
- rcu_read_unlock();
}
int vgic_its_resolve_lpi(struct kvm *kvm, struct vgic_its *its,
@@ -1725,8 +1726,10 @@ static void vgic_mmio_write_its_ctlr(struct kvm *kvm, struct vgic_its *its,
goto out;
its->enabled = !!(val & GITS_CTLR_ENABLE);
- if (!its->enabled)
+ if (!its->enabled) {
+ guard(mutex)(&its->its_lock);
vgic_its_invalidate_cache(its);
+ }
/*
* Try to process any pending commands. This function bails out early
--
2.43.0
reply other threads:[~2026-06-02 7:52 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=ah6Lsi4MfKUU6wBR@v4bel \
--to=imv4bel@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kees@kernel.org \
--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=seiden@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.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