Re: [PATCH net] net/mlx5e: Skip NAPI polling when PCI channel is offline

[Breno Leitao <leitao@debian.org>]

On Tue, Feb 10, 2026 at 10:19:46AM +0800, Jijie Shao wrote:
> 
> on 2026/2/10 2:01, Breno Leitao wrote:
> > 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