From nobody Wed Dec 17 14:23:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 B52BB17BA1 for ; Fri, 13 Dec 2024 01:19:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734052772; cv=none; b=iCFYgJqvR8oYkpy+Jr0w5L02jAlMV/nnkR+KgOALNc2XSn80B0pio7eCjqyucYATeMchrSmbRMuSTaZVFO7kfwsBe4jzfZAtLzbxWVTlm9bsrzE/SADNTfRLo2rtYYVH+pxWlBuC7tY7Yvr7rcZwKnbgnWTfgc8G4sLGslppttY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734052772; c=relaxed/simple; bh=jhoSJv0G7JOBom4scM9bS6XGif5FA4Y6amjcXDcKrok=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jJaAhgGoJBBhATixRI0LKNodoIhgCLVenx1GqLJT0cYrFbVs9e6RCK48Iw04EIsJUKqwScmW4M+gDs5/f3phkWRmh8KrP+qTz3V1I2mLnaRNH7gabxBOwJ052yTd5TaklNfTsQpxS03ISaLQRwgn38DcKLAdf1QI96CQGr0VdmA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MSt52rM3; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="MSt52rM3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1734052770; x=1765588770; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jhoSJv0G7JOBom4scM9bS6XGif5FA4Y6amjcXDcKrok=; b=MSt52rM382LKf8UYHPUCJ1aplbAtMB01yPPrriQ6M3SOmIsWH2LbT62N a/wn07+1pRJXOdwRwLFnUsGqCU22rKCCAVQ0F8NlfMfWqBVyFilUnzKWJ R1Ogv8UezoSM5bXkAzzGIp3yUA3gi4kfeLOPfWoGm7wMC+BdQP9FAugN6 G2ju8xGDPrpFej28dflWIiB2ABGq1USkE/6MNXouBmfN6yfotkGG0w28V 9Lzw45D7EOa2PqLlBMUjn1kVIkhg9S3VKLoMxGKe8vOq+12o3eyNcmZy9 plStRa3rhj27yEIn978qJD4uCRAdtNtGXiZtTslTEuCDeRCaX1TNcJhB/ Q==; X-CSE-ConnectionGUID: 8SXgA0HAR0uYTFButOzahA== X-CSE-MsgGUID: gCWolc/fS7aJ1V6AprbCHQ== X-IronPort-AV: E=McAfee;i="6700,10204,11282"; a="45510010" X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="45510010" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2024 17:19:29 -0800 X-CSE-ConnectionGUID: +GzNBlz1T2mZvxJZM/xLyg== X-CSE-MsgGUID: fFODMDO9TfSO1xIKkCW/vA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="96835611" Received: from allen-sbox.sh.intel.com ([10.239.159.30]) by orviesa007.jf.intel.com with ESMTP; 12 Dec 2024 17:19:28 -0800 From: Lu Baolu To: Joerg Roedel Cc: Dan Carpenter , Yi Liu , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 1/3] iommu/vt-d: Remove cache tags before disabling ATS Date: Fri, 13 Dec 2024 09:17:50 +0800 Message-ID: <20241213011752.1177061-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241213011752.1177061-1-baolu.lu@linux.intel.com> References: <20241213011752.1177061-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" The current implementation removes cache tags after disabling ATS, leading to potential memory leaks and kernel crashes. Specifically, CACHE_TAG_DEVTLB type cache tags may still remain in the list even after the domain is freed, causing a use-after-free condition. This issue really shows up when multiple VFs from different PFs passed through to a single user-space process via vfio-pci. In such cases, the kernel may crash with kernel messages like: BUG: kernel NULL pointer dereference, address: 0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2 RIP: 0010:cache_tag_flush_range+0x9b/0x250 Call Trace: ? __die+0x1f/0x60 ? page_fault_oops+0x163/0x590 ? exc_page_fault+0x72/0x190 ? asm_exc_page_fault+0x22/0x30 ? cache_tag_flush_range+0x9b/0x250 ? cache_tag_flush_range+0x5d/0x250 intel_iommu_tlb_sync+0x29/0x40 intel_iommu_unmap_pages+0xfe/0x160 __iommu_unmap+0xd8/0x1a0 vfio_unmap_unpin+0x182/0x340 [vfio_iommu_type1] vfio_remove_dma+0x2a/0xb0 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0xafa/0x18e0 [vfio_iommu_type1] Move cache_tag_unassign_domain() before iommu_disable_pci_caps() to fix it. Fixes: 3b1d9e2b2d68 ("iommu/vt-d: Add cache tag assignment interface") Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20241129020506.576413-1-baolu.lu@linux.inte= l.com --- drivers/iommu/intel/iommu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 7d0acb74d5a5..79e0da9eb626 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3220,6 +3220,9 @@ void device_block_translation(struct device *dev) struct intel_iommu *iommu =3D info->iommu; unsigned long flags; =20 + if (info->domain) + cache_tag_unassign_domain(info->domain, dev, IOMMU_NO_PASID); + iommu_disable_pci_caps(info); if (!dev_is_real_dma_subdevice(dev)) { if (sm_supported(iommu)) @@ -3236,7 +3239,6 @@ void device_block_translation(struct device *dev) list_del(&info->link); spin_unlock_irqrestore(&info->domain->lock, flags); =20 - cache_tag_unassign_domain(info->domain, dev, IOMMU_NO_PASID); domain_detach_iommu(info->domain, iommu); info->domain =3D NULL; } --=20 2.43.0 From nobody Wed Dec 17 14:23:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 718EA1426C for ; Fri, 13 Dec 2024 01:19:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734052773; cv=none; b=Lu+zOoCul7h5jUb4wufmtxUsT0MVkuJi2ozDtm4SInQISpo/lWkvTrRJD2j9DLOUc3P4WJNAPjAdVvhRrWm/yLGolwi/9/uVoKnb1RKxGzDm4qPLUax8zZKF0tF9eZ0n/FYG1S+Z2Wacmhf7WIfpI0zaVNPzrGrP7JBQHtOlVPg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734052773; c=relaxed/simple; bh=oFTAE7oILI0nnbHGudLD0dYAdhiiCnQbK/kloxuCPM4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Cl/WwCbDhTwwzPgMvi3yjesWG9nI8le95fNP25AvvklFGMVgsw8BJeaQHrCg+CC121OqtLHzaCPou8NMQ8pk6uudHdDguezewgiC3aoKtZ1RbmTg+hKIUbUh35VUkkP1dcmmmcJN4hf49mNXJ0LJVXN/i58ebtyRVyypl1DGGT0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Hj1nCrmu; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="Hj1nCrmu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1734052772; x=1765588772; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=oFTAE7oILI0nnbHGudLD0dYAdhiiCnQbK/kloxuCPM4=; b=Hj1nCrmuOfuGm9RFMWK204JyoCQyppsEXDfFrm2RFdAhQN5iCr8M+WAL zmntgoe9XL3fRaHgI+K/MDZjAL+YiS4I8rbp/ZFG/wXJ/V2km4RzblQXs DhQju9pTLI1pLb+JcDUBzq5wSFZ+bU6pPpc2jS/mtAQr3aqA+WqMnY+l0 GU4hcDN7LdKqNLQ1XSK9Nxjs7cMd3Ot+KklL6LASCJ24KvUbCrb0CHL8e xqvFnCChLKV6UE0TrhyG69D6ALYtSzAcBtqxwS5w6moeFQtALbXgIp4UB S+iKgNfxlxR5kelFTeTSESMOsXzxWdbLMKHIsHGOjEUN2GeKi5ZFGx9rM Q==; X-CSE-ConnectionGUID: BZ9wsG02SQyG8fqp0epb/w== X-CSE-MsgGUID: 8pnPFh+GS2mFYu/AtTizqw== X-IronPort-AV: E=McAfee;i="6700,10204,11282"; a="45510016" X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="45510016" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2024 17:19:31 -0800 X-CSE-ConnectionGUID: sjSfKWVZSyG+SPkpKWQk6w== X-CSE-MsgGUID: FV7igCqmRqCVX/3r1uCpLg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="96835622" Received: from allen-sbox.sh.intel.com ([10.239.159.30]) by orviesa007.jf.intel.com with ESMTP; 12 Dec 2024 17:19:30 -0800 From: Lu Baolu To: Joerg Roedel Cc: Dan Carpenter , Yi Liu , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 2/3] iommu/vt-d: Fix qi_batch NULL pointer with nested parent domain Date: Fri, 13 Dec 2024 09:17:51 +0800 Message-ID: <20241213011752.1177061-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241213011752.1177061-1-baolu.lu@linux.intel.com> References: <20241213011752.1177061-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" From: Yi Liu The qi_batch is allocated when assigning cache tag for a domain. While for nested parent domain, it is missed. Hence, when trying to map pages to the nested parent, NULL dereference occurred. Also, there is potential memleak since there is no lock around domain->qi_batch allocation. To solve it, add a helper for qi_batch allocation, and call it in both the __cache_tag_assign_domain() and __cache_tag_assign_parent_domain(). BUG: kernel NULL pointer dereference, address: 0000000000000200 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8104795067 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 223 UID: 0 PID: 4357 Comm: qemu-system-x86 Not tainted 6.13.0-rc1-00= 028-g4b50c3c3b998-dirty #2632 Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x80/0x150 ? do_user_addr_fault+0x63/0x7b0 ? exc_page_fault+0x7c/0x220 ? asm_exc_page_fault+0x26/0x30 ? cache_tag_flush_range_np+0x13c/0x260 intel_iommu_iotlb_sync_map+0x1a/0x30 iommu_map+0x61/0xf0 batch_to_domain+0x188/0x250 iopt_area_fill_domains+0x125/0x320 ? rcu_is_watching+0x11/0x50 iopt_map_pages+0x63/0x100 iopt_map_common.isra.0+0xa7/0x190 iopt_map_user_pages+0x6a/0x80 iommufd_ioas_map+0xcd/0x1d0 iommufd_fops_ioctl+0x118/0x1c0 __x64_sys_ioctl+0x93/0xc0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 705c1cdf1e73 ("iommu/vt-d: Introduce batched cache invalidation") Cc: stable@vger.kernel.org Co-developed-by: Lu Baolu Signed-off-by: Lu Baolu Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20241210130322.17175-1-yi.l.liu@intel.com --- drivers/iommu/intel/cache.c | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/intel/cache.c b/drivers/iommu/intel/cache.c index e5b89f728ad3..09694cca8752 100644 --- a/drivers/iommu/intel/cache.c +++ b/drivers/iommu/intel/cache.c @@ -105,12 +105,35 @@ static void cache_tag_unassign(struct dmar_domain *do= main, u16 did, spin_unlock_irqrestore(&domain->cache_lock, flags); } =20 +/* domain->qi_batch will be freed in iommu_free_domain() path. */ +static int domain_qi_batch_alloc(struct dmar_domain *domain) +{ + unsigned long flags; + int ret =3D 0; + + spin_lock_irqsave(&domain->cache_lock, flags); + if (domain->qi_batch) + goto out_unlock; + + domain->qi_batch =3D kzalloc(sizeof(*domain->qi_batch), GFP_ATOMIC); + if (!domain->qi_batch) + ret =3D -ENOMEM; +out_unlock: + spin_unlock_irqrestore(&domain->cache_lock, flags); + + return ret; +} + static int __cache_tag_assign_domain(struct dmar_domain *domain, u16 did, struct device *dev, ioasid_t pasid) { struct device_domain_info *info =3D dev_iommu_priv_get(dev); int ret; =20 + ret =3D domain_qi_batch_alloc(domain); + if (ret) + return ret; + ret =3D cache_tag_assign(domain, did, dev, pasid, CACHE_TAG_IOTLB); if (ret || !info->ats_enabled) return ret; @@ -139,6 +162,10 @@ static int __cache_tag_assign_parent_domain(struct dma= r_domain *domain, u16 did, struct device_domain_info *info =3D dev_iommu_priv_get(dev); int ret; =20 + ret =3D domain_qi_batch_alloc(domain); + if (ret) + return ret; + ret =3D cache_tag_assign(domain, did, dev, pasid, CACHE_TAG_NESTING_IOTLB= ); if (ret || !info->ats_enabled) return ret; @@ -190,13 +217,6 @@ int cache_tag_assign_domain(struct dmar_domain *domain, u16 did =3D domain_get_id_for_dev(domain, dev); int ret; =20 - /* domain->qi_bach will be freed in iommu_free_domain() path. */ - if (!domain->qi_batch) { - domain->qi_batch =3D kzalloc(sizeof(*domain->qi_batch), GFP_KERNEL); - if (!domain->qi_batch) - return -ENOMEM; - } - ret =3D __cache_tag_assign_domain(domain, did, dev, pasid); if (ret || domain->domain.type !=3D IOMMU_DOMAIN_NESTED) return ret; --=20 2.43.0 From nobody Wed Dec 17 14:23:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 C843A42A97 for ; Fri, 13 Dec 2024 01:19:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734052776; cv=none; b=fhD6KHBP24qfWqnl/aPyEStQpcDHvj2ONLJrmZJR5j3xcTVRpAIq2A9/SPTZyK3+kZQRisGT7dc6v2y3MijvXBvFLm97Za/quX9jMYJT13Njz9JYtdK0pmsVv/51NHyFz+3HdyxjSsUFLkcR0XnhL56pOWc/X19nX3D3/2mgmOo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734052776; c=relaxed/simple; bh=LI4TUKQcvu8NMrFjCnSkKO5OlCTfkkPU/tftsaNGm9Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PGSBXKdJKy2Qbyg/gNNDqOeOz8/W9z+DliInujSkJkNQeOOcmkk+CsHkxQzAmFu0HMzRwDMU9siXdpJOdMpA791dZELqJyV+MpjQXvdCoAdKscjA4dXMvq8uY4qGiJp+Joi5nmPYUi9Uu3h9gx2P9XkIeXOgcTPeG7ZW3N0SFHU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=G8yQ9iSS; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="G8yQ9iSS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1734052774; x=1765588774; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=LI4TUKQcvu8NMrFjCnSkKO5OlCTfkkPU/tftsaNGm9Y=; b=G8yQ9iSSSoIk0ghk7D+Q6AoyUMrqepnFy/XWGP0xu3DqA4uBSsWK4tBC 1TDt7PZPjV/Dmy1beMuUtH5YGAvipkV/KSFdE6KP+C+N6+ZATzF3+eQgO WhZud7mQgySN0asFHGwVmccazDY4kTU1wx7YCOEv+zBYFroni4J9mM7TI I7FBJQ7p0mWDEy4/sLthpUmoL0MV6DEyPJtfv9uCnBMIBHLc4UtBxX/8K tpf78vEYUFNNMDZGPRig/AAzwEHKs/tlM0GEOpkAv/46iDTRhhg0nV6N8 4HvnoPwb88wfVMa0zVr2FmI9hZCXZ1THCprAjKHnlHbfqpkZ7lfI5Qv2D A==; X-CSE-ConnectionGUID: nX9f1cGPQz69DDw3qIFj8g== X-CSE-MsgGUID: 4gmuDOKURWieeBgaPgVaJg== X-IronPort-AV: E=McAfee;i="6700,10204,11282"; a="45510022" X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="45510022" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2024 17:19:33 -0800 X-CSE-ConnectionGUID: cZLgcs2cTW6maeyaHdtyjQ== X-CSE-MsgGUID: d3uU5sVFSpSfPRYoNviNZQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="96835641" Received: from allen-sbox.sh.intel.com ([10.239.159.30]) by orviesa007.jf.intel.com with ESMTP; 12 Dec 2024 17:19:32 -0800 From: Lu Baolu To: Joerg Roedel Cc: Dan Carpenter , Yi Liu , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] iommu/vt-d: Avoid draining PRQ in sva mm release path Date: Fri, 13 Dec 2024 09:17:52 +0800 Message-ID: <20241213011752.1177061-4-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241213011752.1177061-1-baolu.lu@linux.intel.com> References: <20241213011752.1177061-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 a PASID is used for SVA by a device, it's possible that the PASID entry is cleared before the device flushes all ongoing DMA requests and removes the SVA domain. This can occur when an exception happens and the process terminates before the device driver stops DMA and calls the iommu driver to unbind the PASID. There's no need to drain the PRQ in the mm release path. Instead, the PRQ will be drained in the SVA unbind path. Unfortunately, commit c43e1ccdebf2 ("iommu/vt-d: Drain PRQs when domain removed from RID") changed this behavior by unconditionally draining the PRQ in intel_pasid_tear_down_entry(). This can lead to a potential sleeping-in-atomic-context issue. Smatch static checker warning: drivers/iommu/intel/prq.c:95 intel_iommu_drain_pasid_prq() warn: sleeping in atomic context To avoid this issue, prevent draining the PRQ in the SVA mm release path and restore the previous behavior. Fixes: c43e1ccdebf2 ("iommu/vt-d: Drain PRQs when domain removed from RID") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-iommu/c5187676-2fa2-4e29-94e0-4a279dc= 88b49@stanley.mountain/ Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20241212021529.1104745-1-baolu.lu@linux.int= el.com --- drivers/iommu/intel/pasid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index 0f2a926d3bd5..5b7d85f1e143 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -265,7 +265,8 @@ void intel_pasid_tear_down_entry(struct intel_iommu *io= mmu, struct device *dev, iommu->flush.flush_iotlb(iommu, did, 0, 0, DMA_TLB_DSI_FLUSH); =20 devtlb_invalidation_with_pasid(iommu, dev, pasid); - intel_iommu_drain_pasid_prq(dev, pasid); + if (!fault_ignore) + intel_iommu_drain_pasid_prq(dev, pasid); } =20 /* --=20 2.43.0