Re: [PATCH stable 6.12 0/2] iommu/vt-d+dma: fix stale DMA PTE WARN on IOVA reuse (regression v6.12.75)

[Robin Murphy <robin.murphy@arm.com>]

On 2026-04-23 11:09 am, avinash pal wrote:
> Two-patch series addressing the stale-DMA-PTE WARN_ON regression that
> hits kernels 6.12.75 and 6.12.76 when Intel IOMMU is enabled.
> 
>    Bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=221389

That appears to be some tracing tool bug?

>    Unaffected: v6.12.74   (confirmed: Giovanni Pancotti, 2026-04-22)
>    Affected  : v6.12.76   (WARN on ATA/SCSI DMA workloads)
>    Workaround: intel_iommu=off
> 
> Root cause
> ==========
> The lazy-flush path in __iommu_dma_unmap_sg() releases an IOVA back to
> the allocator via free_iova_fast() before iommu_iotlb_sync() drains the
> hardware TLB.  A concurrent map() on the same domain receives the same
> IOVA and hits a live PTE in __domain_mapping():

And sorry, but all of this is such complete and utter nonsense that I 
can only assume it's AI slop, as I can't imagine any motivated human 
developer investing the effort to be so wrong in such an intricate level 
of detail.

If the pagetables have got out of sync with the IOVA state because some 
DMA API caller passed the wrong address/size to dma_unmap_*, that's a 
bug in whatever drivers/subsystem is making the DMA API calls - try 
throwing CONFIG_DMA_API_DEBUG at it.

>    CPU 0 (unmap, lazy path)        CPU 1 (concurrent map)
>    ──────────────────────────      ───────────────────────────────
>    iommu_unmap(iova)
>    free_iova_fast(iova)  ← live
>                                    alloc_iova_fast() → same iova
>                                    __domain_mapping()
>                                      dma_pte_present() == true
>                                      WARN_ON_ONCE()          ← hit
> 
> Patches
> =======
> 1/2  iommu/vt-d: fail map loudly on stale DMA PTE
>       - Replaces bare WARN(1,...) with pr_err_ratelimited + WARN_ON_ONCE
>       - Prints vPFN + old PTE value for debugging
>       - Returns -EEXIST; no silent double-map
> 
> 2/2  iommu/dma: sync IOTLB before releasing IOVA on sg unmap
>       - Adds iommu_iotlb_sync() before free_iova_fast() on lazy path
>       - Closes the race window; strict-mode path already does this
> 
> ACTION NEEDED by reviewer: run
>    git log v6.12.74..v6.12.76 -- drivers/iommu/dma-iommu.c
> to identify the offending commit for the Fixes: tag in patch 2/2.

No, that's not how upstream review works. However, since I can guess the 
outcome already:

~/src/linux$ git log v6.12.74..v6.12.76 -- drivers/iommu/dma-iommu.c
~/src/linux$

Oh dear, there were no changes at all!? But... that could only mean that 
the nonsensical hypothesis dreamed up by overpowered autocomplete was in 
fact not true. How could this be!?

Thanks,
Robin.

> 
> avinash pal (2):
>    iommu/vt-d: fail map loudly on stale DMA PTE
>    iommu/dma: sync IOTLB before releasing IOVA on sg unmap
> 
>   drivers/iommu/dma-iommu.c   |  9 +++++++
>   drivers/iommu/intel/iommu.c | 50 ++++++++++++++++++++++++++++---------
>   2 files changed, 47 insertions(+), 12 deletions(-)
> 
> 
> base-commit: 444b39ef6108313e8452010b22aaba588e8fb92b