iommu/vt-d+dma: fix stale DMA PTE WARN on IOVA reuse (regression v6.12.75)

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

Posted by avinash pal 1 month, 3 weeks ago

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
  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():

  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.

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
-- 
2.53.0

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

Posted by Robin Murphy 1 month, 3 weeks ago

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

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

Posted by Greg KH 1 month, 3 weeks ago

On Thu, Apr 23, 2026 at 03:39:02PM +0530, 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
>   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():
> 
>   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.
> 
> 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
> -- 
> 2.53.0
> 
> 

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>