Re: [PATCH 1/2] iommupt: fix full IOTLB flush from a zero length unmap

[Baolu Lu <baolu.lu@linux.intel.com>]

On 11/5/2026 8:12 PM, YeeLi wrote:
> From: yeeli<seven.yi.lee@gmail.com>
> 
> unmap_range() hands gather_range_pending() the number of bytes it
> actually unmapped, not the requested length. That count is 0 whenever
> the range holds no mappings, so an unmap that removes nothing reaches
> the gather code with len == 0.
> 
> The gather helpers assume a real range: both
> iommu_iotlb_gather_add_range() and iommu_iotlb_gather_is_disjoint()
> compute end = iova + len - 1. For len == 0 this wraps to iova - 1.
> 
> The problem can be reproduced by attaching an empty paging domain to an
> Intel VT-d device and unmapping IOVA 0:
> 
> 	domain = iommu_paging_domain_alloc(dev);
> 	iommu_attach_device(domain, dev);
> 	iommu_unmap(domain, 0, PAGE_SIZE);	/* nothing is mapped */
> 
> The unmap returns 0, but the gather becomes [0, ULONG_MAX] and the
> iotlb_sync() that follows asks the driver to invalidate everything.
> Captured with the cache_tag_flush_range and qi_submit tracepoints
> enabled:
> 
>    cache_tag_flush_range: dmar0 dmar0[0] type iotlb did 12 [0x0-0xffffffffffffffff] addr 0x0 mask 0x34
>    qi_submit: p_iotlb_inv dmar0: 0xc0026 0x0 0x0 0x0
> 
> With a non-zero IOVA the wrapped end widens whatever range has already
> been gathered instead.
> 
> Skip the gather bookkeeping when nothing was unmapped. An untouched
> gather keeps start == ULONG_MAX and end == 0, which iommu_iotlb_sync()
> already ignores.
> 
> Fixes: 7c53f4238aa8 ("iommupt: Add unmap_pages op")
> Signed-off-by: yeeli<seven.yi.lee@gmail.com>
> ---
>   drivers/iommu/generic_pt/iommu_pt.h | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>