Re: [PATCH v4 11/18] PCI: rcar-gen4: Take over the iMSI-RX interrupt

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: dwc: infinite interrupt loop on unmapped MSI
--

commit d7610b61a0b56b2000f9c7946a3b5317c331ed06
Author: Koichiro Den <den@valinux.co.jp>

PCI: rcar-gen4: Take over the iMSI-RX interrupt

On R-Car Gen4 SoCs, intreq_pcim_sub ("msi") carries more than the
integrated MSI receiver. This commit requests the interrupt in the driver
in all configurations and demultiplexes the MSIs through
dw_handle_msi_irq() in a dedicated handler.

> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index 54260e62293b1..d51c0fc5ff363 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c

[ ... ]

> @@ -613,6 +616,54 @@ static int rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>  	return ret;
>  }
>  
> +/*
> + * intreq_pcim_sub carries the iMSI-RX interrupt along with other controller
> + * notifications, so the driver owns it instead of the DesignWare core (see
> + * pp->msi_irq[0]) and demultiplexes the MSIs itself.
> + */
> +static irqreturn_t rcar_gen4_pcie_msi_irq_handler(int irq, void *data)
> +{
> +	struct rcar_gen4_pcie *rcar = data;
> +	u32 status;
> +
> +	status = readl(rcar->base + PCIEINTSTS0) &
> +		 readl(rcar->base + PCIEINTSTS0EN);
> +	if (!(status & MSI_CTRL_INT))
> +		return IRQ_NONE;
> +
> +	dw_handle_msi_irq(&rcar->dw.pp);
> +
> +	return IRQ_HANDLED;
> +}

[Severity: High]
Can this cause an infinite interrupt loop if an unmapped MSI is received?

If a PCIe endpoint sends an unmapped MSI, generic_handle_demux_domain_irq()
returns false.

Because dw_handle_msi_irq() ignores this return value:

drivers/pci/controller/dwc/pcie-designware-host.c:dw_handle_msi_irq() {
        ...
        for_each_set_bit(pos, &status, MAX_MSI_IRQS_PER_CTRL)
                generic_handle_demux_domain_irq(pp->irq_domain, irq_off + pos);
}

The write-1-to-clear hardware status bit in PCIE_MSI_INTR0_STATUS is never
cleared for the unmapped interrupt.

Since rcar_gen4_pcie_msi_irq_handler() unconditionally returns IRQ_HANDLED
when MSI_CTRL_INT is set, the un-cleared bit keeps the interrupt line
asserted. The generic IRQ subsystem's spurious interrupt detector won't step
in to disable the line because the handler claims it handled the interrupt.

Could this introduce a hard lockup if an untrusted endpoint triggers an
unmapped MSI?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015033103.3076869-1-den@valinux.co.jp?part=11