diff options
| author | Honglei Huang <honghuan@amd.com> | 2026-07-03 11:37:29 +0800 |
|---|---|---|
| committer | Marek Szyprowski <m.szyprowski@samsung.com> | 2026-07-13 09:32:01 +0200 |
| commit | 1acce29926d93f3eba427696fe3da6451504dae2 (patch) | |
| tree | fc4a8e782fb60dd0f42ef8474c2ad19f5ad8fb47 /scripts/git.orderFile | |
| parent | dbcc3cd58083521d77f0e43db615bca2c17b0dbf (diff) | |
| download | linux-1acce29926d93f3eba427696fe3da6451504dae2.tar.gz linux-1acce29926d93f3eba427696fe3da6451504dae2.zip | |
iommu/dma: simplify dma_iova_destroy() and drop the free_iova helper
dma_iova_destroy() frees the IOVA space through __iommu_dma_iova_unlink()
using a "free_iova" boolean, which duplicates the IOVA free logic in
dma_iova_free(). And it frees using the unmapped @mapped_len, which for a
partially linked reservation is smaller than the reserved size. This
results in a benign waste as pointed out by Robin, not a leak. So this is
a cleanup, not a fix.
Drop the duplicated free path. Fold __iommu_dma_iova_unlink into
dma_iova_unlink and remove the free_iova parameter so it only unmaps.
dma_iova_destroy then unlinks the mapped range if mapped_len is set and
unconditionally calls dma_iova_free, which frees the whole reservation
via dma_iova_size. The freed size now always matches the reserved size,
and destroy reads as unlink then free.
Note that dma_iova_destroy() no longer routes the free through the flush
queue; teardown now unmaps synchronously and frees directly, matching
dma_iova_free().
No functional change intended for callers.
Suggested-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Honglei Huang <honghuan@amd.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260703033729.455358-1-honghuan@amd.com
Diffstat (limited to 'scripts/git.orderFile')
0 files changed, 0 insertions, 0 deletions
