Re: [PATCH] PCI: dwc: ep: Fix regression in dw_pcie_ep_raise_msi_irq()

[Niklas Cassel <cassel@kernel.org>]

On Tue, Feb 10, 2026 at 02:39:49PM -0600, Bjorn Helgaas wrote:
> On Tue, Feb 10, 2026 at 09:22:58PM +0100, Niklas Cassel wrote:
> > On Tue, Feb 10, 2026 at 01:32:05PM -0600, Bjorn Helgaas wrote:
> 
> The scenario I'm asking about is the following, where the single
> change of MSI target as the host boots is concurrent with
> dw_pcie_ep_raise_msi_irq()::
> 
>   - host writes PCI_MSI_ADDRESS_LO
> 
>   - dw_pcie_ep_raise_msi_irq() reads PCI_MSI_ADDRESS_LO and
>     PCI_MSI_ADDRESS_HI
> 
>   - dw_pcie_ep_raise_msi_irq() maps msg_addr built from an old
>     PCI_MSI_ADDRESS_HI and a new PCI_MSI_ADDRESS_LO
> 
>   - host writes PCI_MSI_ADDRESS_HI
> 
> This could be mitigated by re-reading PCI_MSI_ADDRESS_* to detect the
> tearing.

Ok, now I understand.

This must be extremely unlikely to happen.

Since the host writes the MSI target address very early, before even
enumerating the bus.

So the EP reading a half updated 64-bit MSI address, seems very
unlikely.

Even in the NVMe EPF case, after UEFI loads Linux, there will be no one
posting new Submission Queue Entries, so the EP will not be raising any
interrupts.

If you want to create a misbehaving device that does an interrupt storm
during boot, it might be possible to hit the half updated 64-bit MSI
address race.

If anyone wants to write a patch that avoids that theoretical race,
fine with me, but I don't think we should do anything to avoid it in
this patch, as this theoretical race could happen even before we did
any caching of the MSI target address.


Kind regards,
Niklas