Re: [PATCH net] net/mlx5e: Skip NAPI polling when PCI channel is offline
From: Breno Leitao
Date: Tue Feb 10 2026 - 10:19:32 EST
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