Re: [PATCH v2 2/2] PCI: dwc: ep: Fix unmap potentially unmapping the wrong iATU

Manivannan Sadhasivam <[email protected]> Mon, 3 Aug 2026 19:02:04 +0200
Newsgroups dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-pci
Message-ID <fjib2gdwwmg3qlvjrwy74dt6on4onkj6ynlueqbbuk7gefffxz@rbl57aj3vpz7>
On Thu, Jul 30, 2026 at 04:16:24PM +0200, Niklas Cassel wrote:
> On Thu, Jul 30, 2026 at 01:51:16PM +0000, [email protected] wrote:
> > New issues:
> > - [High] Using `readl()` on the host's MSI target address to flush posted writes generates a dangerous PCIe Memory Read Request, causing kernel panics.
> 
> (snip)
> 
> > [Severity: High]
> > Does using readl() on the host's MSI target address generate a dangerous
> > non-posted PCIe Memory Read Request?
> > 
> > Most host interrupt controllers (like GIC ITS or APIC) do not support reads
> > to their doorbell addresses and will reply with an Unsupported Request (UR).
> > 
> > The DWC controller translates the UR completion into an AXI Slave Error,
> > which can trigger a synchronous external abort and kernel panic on the
> > endpoint CPU.
> > 
> > This concern applies to flushing posted writes in both
> > dw_pcie_ep_raise_msix_irq() and dw_pcie_ep_raise_msi_irq().
> > 
> > > +		dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->msi_mem_phys);
> > > +		ep->msi_iatu_mapped = false;
> > > +	}
> > > +
> > >  	msg_addr = dw_pcie_ep_align_addr(epc, msg_addr, &map_size, &offset);
> > 
> 
> I don't see how this comment is valid.
> 
> I tested this patch with two Rock 5Bs, one in EP mode and one in RC mode.
> 
> The PCIe controller on the host:
> https://github.com/torvalds/linux/blob/v7.2-rc5/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi#L370
> is indeed using GIC ITS, and I saw no issues at all.
> 
> Additionally, we have already been doing a readl() on the MSI-X target
> address, for every single MSI-X, since commit c22533c66cca ("PCI: dwc: ep:
> Flush MSI-X write before unmapping its ATU entry"), first included in
> v7.0-rc2, and not a single soul has complained since then.
> 
> So personally I am not too concerned.
> 

So either the readl() is not generating a PCIe MRd TLP or the host is not
generating UR for the MRd TLP which ends up crashing the Endpoint. In any case,
since the MSI-X read-back was present for a while, we don't need to worry about
this theory.

- Mani

-- 
மணிவண்ணன் சதாசிவம்