* [PATCH] commit 6b080c4e815ceba3c08ffa980c858595c07e786a upstream
@ 2025-10-01 21:19 Zhichuang Sun
2025-10-02 5:16 ` Greg KH
0 siblings, 1 reply; 3+ messages in thread
From: Zhichuang Sun @ 2025-10-01 21:19 UTC (permalink / raw)
To: stable
Cc: Zhichuang Sun, Nadav Amit, Joerg Roedel, Will Deacon,
Robin Murphy, Lu Baolu, iommu
iommu/amd: fix amd iotlb flush range in unmap
This was fixed in mainline in 6b080c4e815ceba3c08ffa980c858595c07e786a,
but do not backport the full refactor.
Targeting branch lts linux-5.15.y.
AMD IOMMU driver supports power of 2 KB page size, it can be 4K, 8K,
16K, etc. So when VFIO driver ask AMD IOMMU driver to unmap a
IOVA with a page_size 4K, it actually can unmap a page_size of
8K, depending on the page used during mapping. However, the iotlb
gather function use the page_size as the range of unmap range,
instead of the real unmapped page size r.
This miscalculation of iotlb flush range will make the unflushed
IOTLB entry stale. It triggered hard-to-debug silent data corruption
issue as DMA engine who used the stale IOTLB entry will DMA into
unmapped memory region.
The upstream commit aims at changing API from map/unmap_page() to
map/unmap_pages() and changed the gather range calculation along
with it. It accidentally fixed this bug in the mainline since 6.1.
For this backport, we don't backport the API change, only port the
gather range calculation to fix the bug.
Cc: Nadav Amit <namit@vmware.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Cc: iommu@lists.linux-foundation.org
Fixes: fc65d0acaf23179b94de399c204328fa259acb90
Signed-off-by: Zhichuang Sun <zhichuang@google.com>
---
drivers/iommu/amd/iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 714c78bf69db..d3a11be8d1dd 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2121,7 +2121,8 @@ static size_t amd_iommu_unmap(struct iommu_domain *dom, unsigned long iova,
r = (ops->unmap) ? ops->unmap(ops, iova, page_size, gather) : 0;
- amd_iommu_iotlb_gather_add_page(dom, gather, iova, page_size);
+ if (r)
+ amd_iommu_iotlb_gather_add_page(dom, gather, iova, r);
return r;
}
--
2.51.0.618.g983fd99d29-goog
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] commit 6b080c4e815ceba3c08ffa980c858595c07e786a upstream
2025-10-01 21:19 [PATCH] commit 6b080c4e815ceba3c08ffa980c858595c07e786a upstream Zhichuang Sun
@ 2025-10-02 5:16 ` Greg KH
2025-10-02 20:49 ` [PATCH v2] " Zhichuang Sun
0 siblings, 1 reply; 3+ messages in thread
From: Greg KH @ 2025-10-02 5:16 UTC (permalink / raw)
To: Zhichuang Sun
Cc: stable, Nadav Amit, Joerg Roedel, Will Deacon, Robin Murphy,
Lu Baolu, iommu
On Wed, Oct 01, 2025 at 09:19:09PM +0000, Zhichuang Sun wrote:
> iommu/amd: fix amd iotlb flush range in unmap
Shouldn't this be the subject line?
> This was fixed in mainline in 6b080c4e815ceba3c08ffa980c858595c07e786a,
> but do not backport the full refactor.
Why not?
> Targeting branch lts linux-5.15.y.
Why just this one? Why not also 5.10.y and 5.4.y?
> AMD IOMMU driver supports power of 2 KB page size, it can be 4K, 8K,
> 16K, etc. So when VFIO driver ask AMD IOMMU driver to unmap a
> IOVA with a page_size 4K, it actually can unmap a page_size of
> 8K, depending on the page used during mapping. However, the iotlb
> gather function use the page_size as the range of unmap range,
> instead of the real unmapped page size r.
>
> This miscalculation of iotlb flush range will make the unflushed
> IOTLB entry stale. It triggered hard-to-debug silent data corruption
> issue as DMA engine who used the stale IOTLB entry will DMA into
> unmapped memory region.
>
> The upstream commit aims at changing API from map/unmap_page() to
> map/unmap_pages() and changed the gather range calculation along
> with it. It accidentally fixed this bug in the mainline since 6.1.
> For this backport, we don't backport the API change, only port the
> gather range calculation to fix the bug.
>
> Cc: Nadav Amit <namit@vmware.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Lu Baolu <baolu.lu@linux.intel.com>
> Cc: iommu@lists.linux-foundation.org
> Fixes: fc65d0acaf23179b94de399c204328fa259acb90
Please use the proper format as documented:
Fixes: fc65d0acaf23 ("iommu/amd: Selective flush on unmap")
thanks,
greg k-h
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH v2] commit 6b080c4e815ceba3c08ffa980c858595c07e786a upstream
2025-10-02 5:16 ` Greg KH
@ 2025-10-02 20:49 ` Zhichuang Sun
0 siblings, 0 replies; 3+ messages in thread
From: Zhichuang Sun @ 2025-10-02 20:49 UTC (permalink / raw)
To: stable
Cc: Zhichuang Sun, Nadav Amit, Joerg Roedel, Will Deacon,
Robin Murphy, Lu Baolu, iommu
iommu/amd: fix amd iotlb flush range in unmap
This was fixed in mainline in 6b080c4e815ceba3c08ffa980c858595c07e786a,
but we do not backport the full patch, only the part that changes IOTLB
flush range calculation(the bug fix part). The other part of the patch
is about API change and refactoring of the code to use the new API, which
are not required for the bug fix. Besides, the API change in AMD IOMMU
driver from map/unmap to map_pages/unmap_pages also has a dependency on
the IOMMU core driver's changes that is not included in 5.15.
This bug fix patch only applies to 5.15.y. For 5.10 LTS and earlier
LTS versions, they don't have selective IOTLB flush support, so this
patch does not apply. For 6.1 and later, they already have the fix
as part of the API change.
AMD IOMMU driver supports power of 2 KB page size, it can be 4K, 8K,
16K, etc. So when VFIO driver ask AMD IOMMU driver to unmap a
IOVA with a page_size 4K, it actually can unmap a page_size of
8K, depending on the page used during mapping. However, the iotlb
gather function use the page_size as the range of unmap range,
instead of the real unmapped page size r.
This miscalculation of iotlb flush range will make the unflushed
IOTLB entry stale. It triggered hard-to-debug silent data corruption
issue as DMA engine who used the stale IOTLB entry will DMA into
unmapped memory region.
Note, the upstream commit aims at changing API from map/unmap_page() to
map/unmap_pages() and changed the gather range calculation along
with it. It accidentally fixed this bug in the mainline since 6.1 without
realizing there was a bug in the old range calculation.
Cc: Nadav Amit <namit@vmware.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Cc: iommu@lists.linux-foundation.org
Fixes: fc65d0acaf23 ("iommu/amd: Selective flush on unmap")
Signed-off-by: Zhichuang Sun <zhichuang@google.com>
---
drivers/iommu/amd/iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 714c78bf69db..d3a11be8d1dd 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2121,7 +2121,8 @@ static size_t amd_iommu_unmap(struct iommu_domain *dom, unsigned long iova,
r = (ops->unmap) ? ops->unmap(ops, iova, page_size, gather) : 0;
- amd_iommu_iotlb_gather_add_page(dom, gather, iova, page_size);
+ if (r)
+ amd_iommu_iotlb_gather_add_page(dom, gather, iova, r);
return r;
}
--
2.51.0.618.g983fd99d29-goog
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-10-02 20:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-01 21:19 [PATCH] commit 6b080c4e815ceba3c08ffa980c858595c07e786a upstream Zhichuang Sun
2025-10-02 5:16 ` Greg KH
2025-10-02 20:49 ` [PATCH v2] " Zhichuang Sun
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox