From nobody Fri Sep 25 19:15:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 73B1A476CD5; Wed, 9 Sep 2026 08:03:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788940993; cv=none; b=i1AB7LWk3P28T0EsRC8gHEahhBB+5wlEB0wdFoyGdDuB957QR7uUm6nAPXBKFf5XZCs81nJ/FUnV36KkGuPS4125UXbjGlfBEMzEw3mW98V6lKoE9vF4fo3MB28R8YuGdpq9lygr7772/tA+lM7GOTm/UfRkpk+0ApF4rk6N+zI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788940993; c=relaxed/simple; bh=/nE+REOqy9M2IpNzvnk2Ic0a9WthxFdNejXS8EPSm94=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Nb9Ed6/Vi4EBHL5bVJdJvOse2FGHtEzKJ4wWjH/ZLzQkJpneH+AgDTW2j3T4e4B/9B4UstH0EDZwHkXG+PWa1ezJL2h+9yH77mKv4RMNwigVF1/27lXwOkxbxtmSkkryeThNVKpm/10CpHtu9i1RlgfKnch0DyHLZozxu16uVBs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nAG1d2HH; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nAG1d2HH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788940993; x=1820476993; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/nE+REOqy9M2IpNzvnk2Ic0a9WthxFdNejXS8EPSm94=; b=nAG1d2HH9weZChH8LQISuE6SDSXM6Yl6x9QHyvOLHETmR5P+/5mORr06 qx4oCtg+M4cYrPSPtDIQX7YqQ35DSIeQl3qVO7W0bPicNIsLrm8aolaHv mJlU+cxyeRNXuxJ0nqB6mplFvkAsepkiDIsjSBW+w+FcekgYpNwWmF/sX 7WbwRWMnvME1z3Zv7TdL45ODiiAdvT/sL5wl5HCjwjq92PobP4IkxMjej dBVRn+nif9+nzSVOgKYxqmfqkdeE8cbfuGZe1ToQkIdBsvNIAjYZ1GZVp /q4Sit+YhOa96anlh714hyENi8t1W/OWp+1OD+X0UdFevpiEC+tdEcttX w==; X-CSE-ConnectionGUID: 6Se2GvrtTfGg+RwrJGUxWQ== X-CSE-MsgGUID: soHA3Ko6Q7i4OV43U4ELkQ== X-IronPort-AV: E=McAfee;i="6800,10657,11900"; a="106726453" X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="106726453" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2026 01:03:13 -0700 X-CSE-ConnectionGUID: ST6kraoGTkmCc0JkTC/pog== X-CSE-MsgGUID: wCwfUJhSS66+LVsNf5f+EQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="301119244" Received: from allen-box.sh.intel.com ([10.239.48.101]) by orviesa002.jf.intel.com with ESMTP; 09 Sep 2026 01:03:10 -0700 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu , stable@vger.kernel.org, Sashiko Subject: [PATCH 1/7] iommu/vt-d: Avoid out-of-range shift in qi_desc_dev_iotlb_pasid() Date: Wed, 9 Sep 2026 15:51:00 +0800 Message-ID: <20260909075106.738691-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260909075106.738691-1-baolu.lu@linux.intel.com> References: <20260909075106.738691-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Callers request a full Device-TLB flush by passing MAX_AGAW_PFN_WIDTH (64 - VTD_PAGE_SHIFT =3D=3D 52) as @size_order. Two expressions in qi_desc_dev_iotlb_pasid() are not prepared for a value that large: unsigned long mask =3D 1UL << (VTD_PAGE_SHIFT + size_order - 1); ... if (!IS_ALIGNED(addr, VTD_PAGE_SIZE << size_order)) The second evaluates to 1UL << 64, which is undefined on all architectures. On x86_64 the shift count masks to zero, IS_ALIGNED(addr, 1) is trivially true, and the alignment sanity check silently degrades into a no-op. The first evaluates to 1UL << 63. That is well defined on 64-bit builds, where unsigned long is 64 bits wide, but is undefined on 32-bit ones. In practice x86 masks the shift count to five bits, so the expression yields 1UL << 31 and ~mask becomes 0x7fffffff. That value is zero-extended when applied to the 64-bit descriptor, so desc->qw1 &=3D ~mask; clears qw1[63:32] as well as bit 31, collapsing the ADDR field that had just been filled with ones. Reaching that requires a scalable-mode PASID configuration on 32-bit x86, which is not a realistic deployment, but the construct is wrong regardless. Compute the mask with BIT_ULL() so that it is 64-bit on every architecture, and skip the alignment check for a full flush, where it is both meaningless and the source of the out-of-range shift. Note that @size_order must not be clamped below 64 - VTD_PAGE_SHIFT. With S set, hardware derives the invalidation range from the least significant zero bit N of ADDR and matches bits [63:N+1] of the incoming address. For size_order 52 the descriptor sets ADDR[63:12] and clears bit 63, making N =3D 63 and the comparison range empty, so everything is invalidated. Reducing @size_order to 51 would instead leave N =3D 62 and cause hardware to compare address bit 63; since callers pass an address of 0, only the lower half of the address space would be invalidated. Bound @size_order at 64 - VTD_PAGE_SHIFT so that a bogus caller cannot reintroduce an out-of-range shift, without altering the full-flush encoding. The non-PASID variant qi_desc_dev_iotlb() already uses 1ULL and is unaffected. Fixes: f701c9f36bcb7 ("iommu/vt-d: Factor out invalidation descriptor compo= sition") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260623060122.3796325-1-guanghuifen= g%40linux.alibaba.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian --- drivers/iommu/intel/iommu.h | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 23dbe6c24439..5b3d234ae265 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1105,12 +1105,20 @@ static inline void qi_desc_dev_iotlb_pasid(u16 sid,= u16 pfsid, u32 pasid, unsigned int size_order, struct qi_desc *desc) { - unsigned long mask =3D 1UL << (VTD_PAGE_SHIFT + size_order - 1); - desc->qw0 =3D QI_DEV_EIOTLB_PASID(pasid) | QI_DEV_EIOTLB_SID(sid) | QI_DEV_EIOTLB_QDEP(qdep) | QI_DEIOTLB_TYPE | QI_DEV_IOTLB_PFSID(pfsid); =20 + /* + * The widest range the descriptor can express is a full flush, encoded + * by making bit 63 the least significant zero bit of ADDR, that is + * @size_order =3D=3D 64 - VTD_PAGE_SHIFT. Bound @size_order there so th= at + * a caller passing something larger cannot produce an out-of-range + * shift below. + */ + if (size_order > 64 - VTD_PAGE_SHIFT) + size_order =3D 64 - VTD_PAGE_SHIFT; + /* * If S bit is 0, we only flush a single page. If S bit is set, * The least significant zero bit indicates the invalidation address @@ -1120,7 +1128,8 @@ static inline void qi_desc_dev_iotlb_pasid(u16 sid, u= 16 pfsid, u32 pasid, * Max Invs Pending (MIP) is set to 0 for now until we have DIT in * ECAP. */ - if (!IS_ALIGNED(addr, VTD_PAGE_SIZE << size_order)) + if (size_order < 64 - VTD_PAGE_SHIFT && + !IS_ALIGNED(addr, BIT_ULL(VTD_PAGE_SHIFT + size_order))) pr_warn_ratelimited("Invalidate non-aligned address %llx, order %d\n", addr, size_order); =20 @@ -1136,7 +1145,7 @@ static inline void qi_desc_dev_iotlb_pasid(u16 sid, u= 16 pfsid, u32 pasid, desc->qw1 |=3D GENMASK_ULL(size_order + VTD_PAGE_SHIFT - 1, VTD_PAGE_SHIFT); /* Clear size_order bit to indicate size */ - desc->qw1 &=3D ~mask; + desc->qw1 &=3D ~BIT_ULL(VTD_PAGE_SHIFT + size_order - 1); /* Set the S bit to indicate flushing more than 1 page */ desc->qw1 |=3D QI_DEV_EIOTLB_SIZE; } --=20 2.43.0 From nobody Fri Sep 25 19:15:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5EA064A1E16 for ; Wed, 9 Sep 2026 08:03:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788940995; cv=none; b=R2tcm0pAlwcKtFGnwCDpiXuKSCh9rg/ZdKyec+n7cjB7OF5pC6gHaV7Cr3ihATMlG3PqxGDHo8NjjbKWJqh5VuzlkNagTWLbncnFXl2Nt3ct2TwaL2se+/RgnfDX6mpiemEyE31Lv5ZVczjYmVOy1XE4/bYMbCIbYeEfGyli4ho= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788940995; c=relaxed/simple; bh=vyYjMjf3vmlIjqvA15FNQsnMHUfwEKOpBSAQ/vbKBjk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ky3ho2kd3uSaYCCp0c3qXl58ZQhsS/Dne0qY1sJVgEuLsek5lsjbuSoReEIWeMEFf+NhQydc53m0UwarMetkS47bHSFS59wJd+jTnZqAtyBOn3a027gJa8m1/OhGC/CvS5ZHhBmktyGF3o/ezigKAnkoRKEafxaw3yp9CjPMquY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Kkuhiy1Q; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Kkuhiy1Q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788940995; x=1820476995; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vyYjMjf3vmlIjqvA15FNQsnMHUfwEKOpBSAQ/vbKBjk=; b=Kkuhiy1Ql48Fzin2QgrzMz6CqzIR5E43pAzvd+ruiZjAbSYJCEFxVtri Gt/fOOXKw7GJqW66dmQ+vq3QBqbrGHX2UrtQQo8fwxYSEBP1M7piYln3J Y3rUwogqwpPojlPxUVgNwMb62ZMSeHhSCu98N4GLl6hv4P+CMp7c0QEgt dTXjudPkASUQIqWoXRIRiPev7lE9Q0w1b8h/5Lhv5cq4bf/bRWY/f5f9a aYPh+ky1ThlRNTXauwRzaL/Mbzt/aEsrb18VQUB0ozEd3fjTc1F/QU1gz 7vDT3ccGRs/JBIJyKhbsjuocMQf6PL11N7CwH7yXtP7YxbXZsaGYm8Mna w==; X-CSE-ConnectionGUID: t/2sCsIvRCOXqZ1iImUZzw== X-CSE-MsgGUID: KfOrvlAkSgSHCr78kSkWGw== X-IronPort-AV: E=McAfee;i="6800,10657,11900"; a="106726462" X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="106726462" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2026 01:03:14 -0700 X-CSE-ConnectionGUID: uxMEKfikTVqQopMTz5feQg== X-CSE-MsgGUID: mxELoZJJSMSDa9PAHPVZdg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="301119251" Received: from allen-box.sh.intel.com ([10.239.48.101]) by orviesa002.jf.intel.com with ESMTP; 09 Sep 2026 01:03:12 -0700 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH 2/7] iommu/vt-d: Do not ignore context table copy failures Date: Wed, 9 Sep 2026 15:51:01 +0800 Message-ID: <20260909075106.738691-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260909075106.738691-1-baolu.lu@linux.intel.com> References: <20260909075106.738691-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" copy_translation_tables() currently logs copy_context_table() failures but still returns success, so partial copy failures are silently ignored. That means Intel IOMMU may run with only part of the old tables copied. Then some old domain IDs may not be reserved, and later may be reused by new domains. With stale hardware cache entries still around, this can cause bad DMA translations, DMA faults, or domain aliasing. Fix by aborting on the first context-table copy failure, freeing temporary context-table pages, and returning an error so caller falls back to a clean root table path. Fixes: f93b4ac5929a ("iommu/vt-d: Use ida to manage domain id") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian --- drivers/iommu/intel/iommu.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 2e3b3ab216f8..38e2a670df9a 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1591,7 +1591,7 @@ static int copy_translation_tables(struct intel_iommu= *iommu) if (ret) { pr_err("%s: Failed to copy context table for bus %d\n", iommu->name, bus); - continue; + goto err_free_ctxt_tbls; } } =20 @@ -1623,11 +1623,27 @@ static int copy_translation_tables(struct intel_iom= mu *iommu) memunmap(old_rt); return 0; =20 +err_free_ctxt_tbls: + /* + * None of these tables have been linked into iommu->root_entry yet, + * so they are unreachable and must be freed here. + */ + for (bus =3D 0; bus < ctxt_table_entries; bus++) + iommu_free_pages(ctxt_tbls[bus]); + kfree(ctxt_tbls); out_unmap: memunmap(old_rt); err_free_bitmap: bitmap_free(iommu->copied_tables); iommu->copied_tables =3D NULL; + + /* + * Only reservations taken from the old context entries can be in the + * ida at this point; no domain has been allocated on this IOMMU yet. + * ida_destroy() empties it and leaves it ready for reuse. + */ + ida_destroy(&iommu->domain_ida); + return ret; } =20 --=20 2.43.0 From nobody Fri Sep 25 19:15:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67B004A2A52 for ; Wed, 9 Sep 2026 08:03:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788940997; cv=none; b=PFrGp/TYifFjDTlT+a0xnpin6NwZ5Ta3PBXuWgUcFZnY0zFS/W19fsC4IB7r0ZYeIWE0wTqpb+X5PiA2On9J3tss6cqbfgNIqTZurH4DCjr6ooRvgjIQw3XT6S3zvljM2HVKAfvmpF8ht7v6I7AL/Qfi5NRGy19p6CLzmCZSXCc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788940997; c=relaxed/simple; bh=hjfteaZqC12weU18xsMmHWkuS6sYcfnjD+saZE1p+XI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PGl9PQRHsm9c3jAWu6LTpw3Hu0ABHDfuBagQ6izzqhLUDaM0ClobTWziBnrXMgOucyyDBrMmCA0LwxU+hR8/zZssPJJYdPfRNJwkW9dPq909YLudpW55sFbsH7qd8mcQn+FvFjqU3j9CMQBzV7j0FEVT/Eh7KmME0rqm5DPgrts= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=DHIOMpjx; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="DHIOMpjx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788940997; x=1820476997; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=hjfteaZqC12weU18xsMmHWkuS6sYcfnjD+saZE1p+XI=; b=DHIOMpjxYfFzlIogSj7hbghHbYm1eedTQEcYsLTlcmvklaDkIODukgO5 e58cnumkK7bTNedAj5nKsrab5iQnGBaB9PegMCNXyon5/vtJvWUK7sHBo OYEtt/EvB1TiDPxG7axkltEodtUwb/L7oySZmssZZuU5iCIsh1HGmE3D7 rPbZHOid+vOJeTdwSFylMP9R8GUQIAES2x/p9kQKkkxMafmO78XeUmDom xt0nICDkRxIf83FJCXOasuMuMC59IrxktpXDfv7hu/CuRNLlshx1h1GfI R8Dr8cAhGkFzGBAk2ktfgeVad60T2w7qzVw4waf7yylAAQRZhMEHWeBUI Q==; X-CSE-ConnectionGUID: u/zzF+auSbGXxE9YJk7Mfw== X-CSE-MsgGUID: G07kSFUhQOu1qthM2h5fuQ== X-IronPort-AV: E=McAfee;i="6800,10657,11900"; a="106726477" X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="106726477" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2026 01:03:17 -0700 X-CSE-ConnectionGUID: RZea4bPDQdiTA5gwnNFf6w== X-CSE-MsgGUID: pbcXGBZ2RNiib8FxlR1NhQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="301119257" Received: from allen-box.sh.intel.com ([10.239.48.101]) by orviesa002.jf.intel.com with ESMTP; 09 Sep 2026 01:03:14 -0700 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH 3/7] iommu/vt-d: Handle DID reservation errors when copying context tables Date: Wed, 9 Sep 2026 15:51:02 +0800 Message-ID: <20260909075106.738691-4-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260909075106.738691-1-baolu.lu@linux.intel.com> References: <20260909075106.738691-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When kdump reuses old translation tables, all old domain IDs (DIDs) must be reserved in the new kernel before new domains are created. Today copy_context_table() ignores ida_alloc_range() return values, so a real -ENOMEM can be missed and an ID may stay unreserved. That can allow DID reuse while stale hardware cache entries still exist, risking domain aliasing. Fix this by moving DID reservation into a helper that: - treats duplicate reservations (-ENOSPC) as expected success, - skips out-of-range IDs as success, - propagates real allocation failures (like -ENOMEM), and - normalize successful return values. On failure, unwind as in existing copy-allocation failure paths. Fixes: f93b4ac5929a ("iommu/vt-d: Use ida to manage domain id") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian --- drivers/iommu/intel/iommu.c | 39 +++++++++++++++++++++++++++++++++---- 1 file changed, 35 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 38e2a670df9a..ab46058d76c5 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1452,12 +1452,39 @@ static void intel_iommu_init_qi(struct intel_iommu = *iommu) } } =20 +/* + * Reserve a domain ID inherited from the previous kernel so that it is not + * handed out again while the copied translation structures are still live. + * + * Returns 0 when the ID is reserved, was already reserved, or cannot be + * re-assigned, and a negative errno for a genuine allocation failure. + */ +static int reserve_domain_id(struct intel_iommu *iommu, int did) +{ + int ret; + + if (did < 0 || did >=3D iommu->max_domain_id) + return 0; + + ret =3D ida_alloc_range(&iommu->domain_ida, did, did, GFP_KERNEL); + /* + * Devices sharing a domain share its ID, so the same ID is seen in + * more than one context entry; -ENOSPC merely reports that it is + * already reserved. On success the allocated ID is returned, which + * is not an error either. + */ + if (ret =3D=3D -ENOSPC || ret >=3D 0) + return 0; + + return ret; +} + static int copy_context_table(struct intel_iommu *iommu, struct root_entry *old_re, struct context_entry **tbl, int bus, bool ext) { - int tbl_idx, tbl_slot =3D 0, idx, devfn, ret =3D 0, did; + int tbl_idx, tbl_slot =3D 0, idx, devfn, ret =3D 0; struct context_entry *new_ce =3D NULL, ce; struct context_entry *old_ce =3D NULL; struct root_entry re; @@ -1520,9 +1547,13 @@ static int copy_context_table(struct intel_iommu *io= mmu, if (!context_present(&ce)) continue; =20 - did =3D context_domain_id(&ce); - if (did >=3D 0 && did < iommu->max_domain_id) - ida_alloc_range(&iommu->domain_ida, did, did, GFP_KERNEL); + ret =3D reserve_domain_id(iommu, context_domain_id(&ce)); + if (ret) { + /* Not yet published through @tbl, so free it here. */ + iommu_free_pages(new_ce); + new_ce =3D NULL; + goto out_unmap; + } =20 set_context_copied(iommu, bus, devfn); new_ce[idx] =3D ce; --=20 2.43.0 From nobody Fri Sep 25 19:15:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B2C34A3D3B for ; Wed, 9 Sep 2026 08:03:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788941000; cv=none; b=omeJ6vzeyTWtau2X3Dr93JQG4creRaiQyS93Ac8NvLYpmIVTj6j3S5p/jdIf2bdTBjDLa/9BTc8Iyw7U1u2WEttCzcGCmskvmWMy7dqKB19YqOtBxV5TXf+uQobiiw+TEp5CzsuUC6McH1CVnFoavixUHvM3SDg1oNfYp7Z+IyE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788941000; c=relaxed/simple; bh=xUrfvEXrKLg0J6GzM68cstBmioplSZGd3x33EWmiOzI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qYTsWT+tl0lpHAbI0IDo05pCACSQenj5G6dyLajr9aBj4GH/sXfb0h49gV1ItJVr4QuaJOqEvMQ0R8FmoneVL9c9ldULZgV7pfUJNv/fppi2YsPYZXTmUSGyOAl3JtHz3ZBU1duGLAe+TjFT/96nyXdg1BwDnjdwHdabiEgECBs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=SE+QfwEL; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="SE+QfwEL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788940999; x=1820476999; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=xUrfvEXrKLg0J6GzM68cstBmioplSZGd3x33EWmiOzI=; b=SE+QfwELdFcd60Ioo+YwT2BSmLeb6m2WsnqO3K55d/KLvjfgBAOtt4id J2c6gIQ/KzvFxkOyNxLiNCMbi6b2hsra0mPC2SBKtyqyFyIQ8t33EbVLX fe8XVLmltIsgDWVL4IJHYNQUDkUmsmdeAnbYi5PjlmJw5XtRxAcqhsBRQ jZudrUV/qPYHp2/B6//ur4QvECoxwHaj94+CdkL5AwQEnPfXRzk6qpjQ6 vcDS3Lo9K8RmPMHSHOw4Z09HTmensBZ/70Fvhb9MIZjcgIGV+sukMyuiZ rbBaC/LtJuwP8cEHbgsWfb5BC212jXVg48ebdxIzj9yzOvCsguVdpZM/U w==; X-CSE-ConnectionGUID: KzJCKSZcSmKdpEuo4I3yRw== X-CSE-MsgGUID: afl6hnFjTBSDAZ5MoDsCXg== X-IronPort-AV: E=McAfee;i="6800,10657,11900"; a="106726491" X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="106726491" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2026 01:03:19 -0700 X-CSE-ConnectionGUID: yBBZEQGtRSScKxyz8KmUTw== X-CSE-MsgGUID: 6Q8/AWqET16xnOsxzYGq7g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="301119266" Received: from allen-box.sh.intel.com ([10.239.48.101]) by orviesa002.jf.intel.com with ESMTP; 09 Sep 2026 01:03:16 -0700 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH 4/7] iommu/vt-d: Reserve scalable-mode DIDs from PASID entries during copy Date: Wed, 9 Sep 2026 15:51:03 +0800 Message-ID: <20260909075106.738691-5-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260909075106.738691-1-baolu.lu@linux.intel.com> References: <20260909075106.738691-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" copy_context_table() reserves old domain IDs (DIDs) from context entries. That works for legacy mode, but not for scalable mode: scalable context entries do not carry DID, so this path ends up reserving the wrong value (often DID 0) repeatedly. In scalable mode, real DIDs are stored in PASID table entries. If they are not reserved during kdump table copy, new domains may reuse old DIDs while stale PASID/IOTLB cache state still exists, causing translation conflicts and DMA faults. Fix this by walking PASID tables in scalable mode, and reserving DIDs from present PASID entries. If PASID structures cannot be remapped, return error so caller can fall back safely instead of continuing with an unsafe DID space. Fixes: 0c5f6c0d8201 ("iommu/vt-d: Fix kdump kernels boot failure with scala= ble mode") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian --- drivers/iommu/intel/iommu.c | 74 ++++++++++++++++++++++++++++++++++++- 1 file changed, 72 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index ab46058d76c5..5553c57130f7 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1479,6 +1479,70 @@ static int reserve_domain_id(struct intel_iommu *iom= mu, int did) return ret; } =20 +/* + * Reserve the domain IDs used by a scalable mode context entry copied from + * the previous kernel. + */ +static int copy_pasid_table_dids(struct intel_iommu *iommu, struct context= _entry *ce) +{ + struct pasid_dir_entry *dir; + unsigned long dir_size; + phys_addr_t dir_phys; + int ret =3D 0; + int i, j; + + dir_phys =3D ce->lo & VTD_PAGE_MASK; + if (!dir_phys) + return 0; + + dir_size =3D get_pasid_dir_size(ce); + dir =3D memremap(dir_phys, dir_size * sizeof(*dir), MEMREMAP_WB); + if (!dir) + return -ENOMEM; + + for (i =3D 0; i < dir_size; i++) { + struct pasid_entry *table; + phys_addr_t table_phys; + + if (!pasid_pde_is_present(&dir[i])) + continue; + + /* + * Do not use get_pasid_table_from_pde(); that returns a + * phys_to_virt() pointer, which is not valid for memory + * owned by the previous kernel. + */ + table_phys =3D READ_ONCE(dir[i].val) & PDE_PFN_MASK; + if (!table_phys) + continue; + + /* A PASID table is one page: PASID_TBL_ENTRIES * 64 bytes. */ + table =3D memremap(table_phys, PAGE_SIZE, MEMREMAP_WB); + if (!table) { + ret =3D -ENOMEM; + goto out; + } + + for (j =3D 0; j < PASID_TBL_ENTRIES; j++) { + if (!pasid_pte_is_present(&table[j])) + continue; + + ret =3D reserve_domain_id(iommu, pasid_get_domain_id(&table[j])); + if (ret) { + memunmap(table); + goto out; + } + } + + memunmap(table); + } + +out: + memunmap(dir); + + return ret; +} + static int copy_context_table(struct intel_iommu *iommu, struct root_entry *old_re, struct context_entry **tbl, @@ -1546,8 +1610,14 @@ static int copy_context_table(struct intel_iommu *io= mmu, =20 if (!context_present(&ce)) continue; - - ret =3D reserve_domain_id(iommu, context_domain_id(&ce)); + /* + * The context entry only holds a domain ID in legacy mode. + * In scalable mode the IDs are in the PASID table entries. + */ + if (ext) + ret =3D copy_pasid_table_dids(iommu, &ce); + else + ret =3D reserve_domain_id(iommu, context_domain_id(&ce)); if (ret) { /* Not yet published through @tbl, so free it here. */ iommu_free_pages(new_ce); --=20 2.43.0 From nobody Fri Sep 25 19:15:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C18546EC98 for ; Wed, 9 Sep 2026 08:03:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788941001; cv=none; b=NOQ08h2GvnLlUwE7+oRN8+9hblm0GYfyO/niohBlftisRTE6ICIa0IrMO3j2gpTtHPlyAAW2v70btmQl7blqqd6jY/uWPpQMdA/V6NIdMgFT7wbxywZ6xT/y1+Oy7c8rGSyPnVwCc694gGt6YEbtB8o02/qvNp8gyMW89hyWzqc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788941001; c=relaxed/simple; bh=2oJBUice+6l/lTky/rYxdZCKGsJLulR5hMAIr01sGnE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qwVI2RLqTxnA05MX7QO6P9XeYwYueRUl6YjZ1+91cYTX7KI2gR/isyQLqjUm4Q/xwvAkENF6K9jLiF3drfY5XeD1nxAdkR/VQoRA/lbY0GIRlEwEHghW+38A7F3BZEzQiirzx79cGZlVx8l8QFBf8rBDTDnrtYnV6GGOnHFqBNg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=YMFNyjtr; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="YMFNyjtr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788941001; x=1820477001; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=2oJBUice+6l/lTky/rYxdZCKGsJLulR5hMAIr01sGnE=; b=YMFNyjtr0V00oE0vU1eArA4RK8qBsqg2xFZDNfxoRdH9h+qR72X9HM8S FBMaq98uHZDRBx5/SFNjc1/EvjNeeAlhrjr7dSRcOpkUBKq/2dZ27L8Os jw4cWN/hTRKqAcLs8cqcHXky4qHcpsGJIac4zCMh1tHYNKwY89Fc0TfrR vHa9mbnDgfbE6Wv1lLP7ySNv1ddrOcDsBwWPuG/eBMWdm38FZT6hnJCXt +FYbaMKZK+3GXvRO2K/NoHWyaafBf3uuV1Szbb9Bg/Z/9ZQ8l1jWuBZfT 4M1ex1HejsMpHSz6Mu+R50GN4CUoAUr92eRFod+PPHrvEtD74qgzAJGtK A==; X-CSE-ConnectionGUID: UDiWrJExRLyObA4teciTYw== X-CSE-MsgGUID: tjQRVt9hQ+i+hURETLC21Q== X-IronPort-AV: E=McAfee;i="6800,10657,11900"; a="106726504" X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="106726504" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2026 01:03:21 -0700 X-CSE-ConnectionGUID: 47K9RuMvTVKmSVwvGuS27g== X-CSE-MsgGUID: 0sHulKHmQSCrOfjHg4/Rgg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="301119276" Received: from allen-box.sh.intel.com ([10.239.48.101]) by orviesa002.jf.intel.com with ESMTP; 09 Sep 2026 01:03:18 -0700 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH 5/7] iommu/vt-d: Use old domain parameter when attaching the blocking domain Date: Wed, 9 Sep 2026 15:51:04 +0800 Message-ID: <20260909075106.738691-6-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260909075106.738691-1-baolu.lu@linux.intel.com> References: <20260909075106.738691-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable blocking_domain_attach_dev() drops the old domain=E2=80=99s iopf reference = using info->domain, but that value may already be cleared by device_block_translation(). On attach failure fallback paths, this can cause the function to drop a NULL-domain ref instead of @old, leaking the real old-domain reference. Repeated leaks grow info->iopf_refcount, keep the device stuck on the iopf queue, and can trigger WARN_ON(info->iopf_refcount) when PRI is disabled. Use the core-provided @old parameter directly. It always identifies the correct domain to release and matches other attach paths. Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian --- drivers/iommu/intel/iommu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 5553c57130f7..99cf6716f602 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2899,9 +2899,7 @@ static int blocking_domain_attach_dev(struct iommu_do= main *domain, struct device *dev, struct iommu_domain *old) { - struct device_domain_info *info =3D dev_iommu_priv_get(dev); - - iopf_for_domain_remove(info->domain ? &info->domain->domain : NULL, dev); + iopf_for_domain_remove(old, dev); device_block_translation(dev); return 0; } --=20 2.43.0 From nobody Fri Sep 25 19:15:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 591D44A441B for ; Wed, 9 Sep 2026 08:03:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788941003; cv=none; b=mNyMcagncBkEZfVYtl8h11OCfFT7+VMXCty6BI/xBtBPqYbAu5738gTl7ylqZjw/0yFuKrbOYS0XepIyfpr61T8fR9uMtopvgMbjZ/83WffNjtabYEZXHjnQIarBFIG/R0Vw0xXQdSDZ4Qo3k6dADgrLCz88x8HBTeB/GMLt5HM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788941003; c=relaxed/simple; bh=+NXG1XAjpq4yG7WqYbUQl5yoKq/wUrSu7mGaGBuE/GA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eH6/aZNGRbSkync6gWMcFlr5a8dqFZdyA+r6J+TdmkFUfMRejxafGSyEs1lYxgp26eoAbcH4KDJBYXbBzX+NsivzQ/IDA9YwwUsVgArEzTdrPf32zLbtn+Jn7VbFCLJ89j2HNIL/u33a+LD9tFfa0tpCQiQmgBVv13R+9rRYbr8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=HQXo2SOH; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="HQXo2SOH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788941003; x=1820477003; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+NXG1XAjpq4yG7WqYbUQl5yoKq/wUrSu7mGaGBuE/GA=; b=HQXo2SOHMVRjUDyAxDOXw8C+69XF+rF8T+Huhni22oKNe0aciU2bvjzQ P2KsJu28kEDAcpjUiXvLnesNgdwaU2V/LnEWwjM4O8caZgo76FCA7SRpx SUc3DfSR79IqtOX2W3lzjh5M7isu6mWrc+ku/AFTdR/XH5hLGJacerUj2 S3+A7h0552M023+TvFDoErlCruOruZM46z5dKIv+ohLanCMG/fi0lw0pq N7QB3Y1WhixK/i79jK5+ft6O21A5uIdQ6eps8TECUXXKEuKYKWOIf34KQ QInuAWVgZVd/TPRvi8aHK+8INXPgsWwtTkekB9UbiBF5YbSNgzZGlmxMu Q==; X-CSE-ConnectionGUID: vxl+NLMUT9uJ6b6F4p3pyA== X-CSE-MsgGUID: 1J4a2PPSRpaEfcPY5awtJA== X-IronPort-AV: E=McAfee;i="6800,10657,11900"; a="106726517" X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="106726517" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2026 01:03:22 -0700 X-CSE-ConnectionGUID: ZXahswviQMei9snYBrN//Q== X-CSE-MsgGUID: T45f6IYST1ywDMHajkBlLg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="301119289" Received: from allen-box.sh.intel.com ([10.239.48.101]) by orviesa002.jf.intel.com with ESMTP; 09 Sep 2026 01:03:20 -0700 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH 6/7] iommu/vt-d: Fix iopf refcount leak in nested attach Date: Wed, 9 Sep 2026 15:51:05 +0800 Message-ID: <20260909075106.738691-7-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260909075106.738691-1-baolu.lu@linux.intel.com> References: <20260909075106.738691-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" intel_nested_attach_dev() takes an iopf reference for the new domain but does not drop the possible reference from the old domain. This leaks info->iopf_refcount, can keep the device permanently on the iopf queue, and later triggers WARN_ON(info->iopf_refcount) when PRI is disabled. Fix this by dropping the possible reference from the old domain after the nested translation setup completes. Fixes: 17fce9d2336d9 ("iommu/vt-d: Put iopf enablement in domain attach pat= h") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian --- drivers/iommu/intel/nested.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/intel/nested.c b/drivers/iommu/intel/nested.c index 2b979bec56ce..f84fc8b41fde 100644 --- a/drivers/iommu/intel/nested.c +++ b/drivers/iommu/intel/nested.c @@ -59,6 +59,8 @@ static int intel_nested_attach_dev(struct iommu_domain *d= omain, if (ret) goto disable_iopf; =20 + iopf_for_domain_remove(old, dev); + info->domain =3D dmar_domain; info->domain_attached =3D true; spin_lock_irqsave(&dmar_domain->lock, flags); --=20 2.43.0 From nobody Fri Sep 25 19:15:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65F214A92FA for ; Wed, 9 Sep 2026 08:03:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788941005; cv=none; b=sus8nK4xaEIYK5Jk7bnZ90iTdgdc4iX+aiXRVVdFdxFvKE5hWCsllHuOURp4tQlvcirOhuw6Bj2k06fBmz/65FgkTNB++GD6Xzgt7AYQDychdpCJxPcO4ofDimwHvHX7wd/CZl6Xyqo7R7TJL+VPNZQcofAJ1LM1osPdSHAcOh0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788941005; c=relaxed/simple; bh=qZ97WV+Bmf61BkqszfOZ/IyHAJ1T40e7IqxYc0omenc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uehFsR/vhMy/DFBadZKVWppKHA0uAUBRZezgaHvYNkSvnf9iuPQ0d3N5V+vFzPbEtgF0NhUk36Ugy2wut6Q0chTRBB0PHHQJ3DBlLbrpqxUBbpikScaBWu5dm+Pcj8iGup4l+S3pGHtLkodbcHv/Ab0cPVqcJMQczHwRB6lkCEA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=RTMGREfj; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="RTMGREfj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788941005; x=1820477005; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=qZ97WV+Bmf61BkqszfOZ/IyHAJ1T40e7IqxYc0omenc=; b=RTMGREfjcC7s0FgCZa405hEhRB8fnsceYardlT6wuRzfvnSQnbl08Bvf 0AhiIEp0PgXYGQRO3gS4QROcj/l5AmqyeT6tn4ekJ9D2DOGkYCfnBeda6 hJ2thmTt65yD8GtaUB4aj+0hFARc5JIDqnnlb1a3QnIizjYmB+vvWvgvP ZUfbsiZ7vx3wUCfo7Eletz9m93ENsy5ZywKlikb+tfdQ21z7vs2ocyyEL iM1CF4E62OLdr3eCW5afWXiu5A4ztAxq0eGsFSfmD6pwlih8+41sqsdHB FBAwmVboKfbFP3uOQE3CImW0ooXKiJYUTUbvVbBhGdyEK4/XVEDJ5ktL0 w==; X-CSE-ConnectionGUID: Kq+x2uCATmic8nBX2uLbkw== X-CSE-MsgGUID: Ti24K10cSs+P58f6zEJWOw== X-IronPort-AV: E=McAfee;i="6800,10657,11900"; a="106726531" X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="106726531" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2026 01:03:24 -0700 X-CSE-ConnectionGUID: 7Fk2oQjRRWmIH01c1CeBFg== X-CSE-MsgGUID: 6F2MB3ptR0CBb/9Ve8Xq4Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,270,1779174000"; d="scan'208";a="301119295" Received: from allen-box.sh.intel.com ([10.239.48.101]) by orviesa002.jf.intel.com with ESMTP; 09 Sep 2026 01:03:22 -0700 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH 7/7] iommu/vt-d: Drop old iopf ref only after attach succeeds Date: Wed, 9 Sep 2026 15:51:06 +0800 Message-ID: <20260909075106.738691-8-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260909075106.738691-1-baolu.lu@linux.intel.com> References: <20260909075106.738691-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable identity_domain_attach_dev() currently removes the old domain=E2=80=99s iopf reference before programming pass-through. If pass-through setup fails, attach fails but the old domain is still effectively attached =E2=80=94 now with its IOPF ref already dropped. This can undercount info->iopf_refcount and may disable iopf queue handling while the old domain can still issue page requests. Fix it by removing the old domain=E2=80=99s iopf reference only after pass-through setup succeeds, matching other attach paths. Fixes: 236dd58fabd2 ("iommu/vt-d: Fix iopf_refcount leak on RID domain repl= acement") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian --- drivers/iommu/intel/iommu.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 99cf6716f602..c1529be63650 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3985,6 +3985,14 @@ static int identity_domain_attach_dev(struct iommu_d= omain *domain, if (dev_is_real_dma_subdevice(dev)) return 0; =20 + if (sm_supported(iommu)) + ret =3D intel_pasid_setup_pass_through(iommu, dev, IOMMU_NO_PASID); + else + ret =3D device_setup_pass_through(dev); + + if (ret) + return ret; + /* * The identity domain has no iopf_handler, so no IOPF reference is * taken for it. The reference held by the old domain must still be @@ -3992,16 +4000,9 @@ static int identity_domain_attach_dev(struct iommu_d= omain *domain, * not affect the IOPF reference count. */ iopf_for_domain_remove(old, dev); + info->domain_attached =3D true; =20 - if (sm_supported(iommu)) - ret =3D intel_pasid_setup_pass_through(iommu, dev, IOMMU_NO_PASID); - else - ret =3D device_setup_pass_through(dev); - - if (!ret) - info->domain_attached =3D true; - - return ret; + return 0; } =20 static int identity_domain_set_dev_pasid(struct iommu_domain *domain, --=20 2.43.0