From nobody Mon Jun 8 04:24:36 2026 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B3AB21ABB1 for ; Tue, 2 Jun 2026 07:52:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780386745; cv=none; b=D8+JOQmjuoBAGBbxLsUnJamedjIxgGT+Q4DzNFO/zPFWtWC01dSYUhxiBRTOoag0IXWq0loff5HykOnnE+/qBNKfX/R3ALNciidoP7Fs2fhbHXJq2dART85EmsNWDu0dZ9KTrIiIqki4Vj/g1A+Pz4c+2P1MmozIFTpIR1u5na0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780386745; c=relaxed/simple; bh=eiSYb56ISqHiWW85Bez4/clFZUsfcUNxHe8kRpVIXmQ=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=mQCcIwUqfdvAhxVGlOPdLm4UWTEd1C7UDUm/7sGgcAv/Y3399fwcOpm5yW+zISR0Oraue0KGGKNKXZab8Rf7KuV7XjtDiqun7pnbjdI7sLnVYM5cc01yrOcOOJ9GZqMnuslsCzu8VpY1PIyI5oP+vu0jIEhvnxAg8G5nhs8Tbwg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Jt8sVGs7; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Jt8sVGs7" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-8424b6792efso528647b3a.3 for ; Tue, 02 Jun 2026 00:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780386743; x=1780991543; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=hP2LSLOcJwd8pqW0+7W9R4omsBDhLT1ZDgtaEvUzbZw=; b=Jt8sVGs7PW5hDokM3WyoGbYSM4xx1e1wwYjyS5AAAE1eTiu0gkU8CEqyODvgg1Gz6/ BLbsslNns58OhmJ2ek+jLflLBD4r+L0X4zrxKMauiYqSFr5BmkwZhBcuyu5zSayKf9HB ItrgYnA+No8DUJitk8xY+HlnvNkbmjQDNWJ/vSTOWDn0OEh4MnScTDhh9qVpoDbUem5T 7aWE+T55RSbdqT8tm1s+2C9Tkxe0rS3OTNrBXswRP5PLEYstzESNcT1CYZDOiFwNgFiw 7Uunm6tYWu8AxNpJW9KGcrPGy8IUn/O0gqW01l1jJ1q+J0pdxB5dA4n+749PXm0BixOB CNNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780386743; x=1780991543; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hP2LSLOcJwd8pqW0+7W9R4omsBDhLT1ZDgtaEvUzbZw=; b=pG9WH7SblLJZICgPCqXqu09wkhfKNVsxyNhDKg3F1trjUledLdeAiMAyGPfIqaT/9L sNdWLMmuaZOWUsq476F+o6hn5Hvwct09HCXTqE2I12appwGjs62l6XYG4uJT0hkiVvjm 51yRZQdAhRkEChS4atkX8P0+bOV7v8azH+nGsPqfEh95L8rrycVORWe0g8l0xSL12Wjk sDBO/3BvVU9CU90Onae9kVN9rY6h51hfktosbdPR/t0TGM4FdcagxP/vQxrryCGL00vA on8++txHftY0exQ2YOYb0mmZmzUuakNakCPMqQ8k12WJ07TyA0CcZFly7uxlwT95IGsB NAXg== X-Forwarded-Encrypted: i=1; AFNElJ8KPALAJeKxYMnj5yHVMT8mx1B8cWtV2uSiRjn8R8XAFda3y7f8C0F1W2RPIEZqYn8GHYSQK3uBSPjlp9U=@vger.kernel.org X-Gm-Message-State: AOJu0YxwglPc4xJgubgf3YyzNuKPs/NxNYF08Ea9qy3A/UJmGRT8jsvo sHTp4GMc8fqZnEX4tiHfZWd0objEuptDcQs4zCc5fS9Tqt7QQDOEKrFj X-Gm-Gg: Acq92OHyxlzWaPj+OcfHfGMyYL0LzRSmsvDyoftyI8wC5eE3GAZyTAwonxqIlodJv0D pgMWG+i4YcgigikrUyWMXmJEHsigjvWzDGN6nOmidzzPcTgpuHdZEGsSIDwSYCmPqWoK2fjpTZE yg75sRDBI0iBzHQfjOJGrofhsyx4jQRUzzU1MBLO1b2Ha9Lx2ZNqV6jOyvzG3IPtrYx8FZe3TMN jsByYi6Q2LbA1iKu7Rnk5V4JQwRBrspZcySwa2ejUHhcdtcadnKsNqsd6qKaEYcDBh7lHkafFbz VYDMWYgEC/YHDlpNOFmUp8IaDZ9KC3CJoOyoSUkRSrDMpKDCNpOKTbohXmt5EUZJPeDFLd0xdYE pOxc8OMIejdo9a+SrtxPY6/NOOQWaIFT4RepZvfGNI1Uj+hN1nAShrBt7cqj0lBHUfSszqAZ4bf snojVgeu0vLhXifNylM0vvL1lMW7vRHZG7tVg8qIcfh6s0zKjdpE6RvTrF2obZqmfz X-Received: by 2002:a05:6a00:3cd3:b0:835:6388:655d with SMTP id d2e1a72fcca58-84225401e17mr12812962b3a.14.1780386743362; Tue, 02 Jun 2026 00:52:23 -0700 (PDT) Received: from v4bel ([58.123.110.97]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8423dc9f361sm7534426b3a.24.2026.06.02.00.52.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 00:52:22 -0700 (PDT) Date: Tue, 2 Jun 2026 16:52:18 +0900 From: Hyunwoo Kim 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 Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 pe= r ITS") Suggested-by: Oliver Upton Signed-off-by: Hyunwoo Kim --- 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; =20 + 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; =20 - rcu_read_lock(); + guard(mutex)(&kvm->lock); =20 - list_for_each_entry_rcu(dev, &kvm->devices, vm_node) { + list_for_each_entry(dev, &kvm->devices, vm_node) { if (dev->ops !=3D &kvm_arm_vgic_its_ops) continue; =20 its =3D dev->private; + guard(mutex)(&its->its_lock); vgic_its_invalidate_cache(its); } - - rcu_read_unlock(); } =20 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; =20 its->enabled =3D !!(val & GITS_CTLR_ENABLE); - if (!its->enabled) + if (!its->enabled) { + guard(mutex)(&its->its_lock); vgic_its_invalidate_cache(its); + } =20 /* * Try to process any pending commands. This function bails out early --=20 2.43.0