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

From: Jijie Shao

Date: Tue Feb 10 2026 - 20:42:32 EST



on 2026/2/10 23:18, Breno Leitao wrote:
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

Thanks for the reply, and I will continue to follow up on this issue.
This change may require further confirmation from the mlx driver's maintainer.

The code look good to me.
Reviewed-by: Jijie Shao <shaojijie@xxxxxxxxxx>