On Tue, Feb 10, 2026 at 10:19:46AM +0800, Jijie Shao wrote:

on 2026/2/10 2:01, Breno Leitao wrote:

quoted

When a PCI error (e.g. AER error or DPC containment) marks the PCI
channel as frozen or permanently failed, the IOMMU mappings for the
device may already be torn down. If mlx5e_napi_poll() continues
processing CQEs in this state, every call to dma_unmap_page() triggers
a WARN_ON in iommu_dma_unmap_phys().

Hi:
  My comment has nothing to do with the changes made in this patch itself.


I am more interested in this error itself.
1. If there is an issue with dma_unmp, does dma_map in tx have a similar problem?

I suspect that dma_map will succeed in such a case (when the DMA maps are
gone). 

dma_map_single/dma_map_page creates new page table entries — it doesn't look up
existing ones. Even if existing mappings are gone, new mappings succeed !?

I haven't seen this instance on the TX path as well.

2. Can this error be detected by mlx5_pci_err_detected()? If not, does this mean that all PCIe NIC drivers might have similar issues?

mlx5_pci_err_detected() is called for the device under DPC — that's not the
issue.

From my naive view, the issue seems to be timing: there's a potential race
between DPC setting the PCI channel to frozen and the error handler completing
(which eventually calls napi_disable_locked).

During that window, NAPI poll can still fire and process CQEs, triggering the
dma_unmap WARN_ON storm, and crash.

   Do other drivers need to do similar checks?

I really don't know, honestly. Are other drivers solving the problem
differently?! 

Thanks for the question,
--breno