Re: [PATCH v2 11/15] PCI: rcar-gen4: Recover the Root Port on link down

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] pci: use-after-free of MSI IRQ domain during host teardown
- [Medium] pci: controller permanently wedged if Root Port removed during link down
--

commit 82b6de1b742f3cf8c20cc9550ebcd54c8a744889
Author: Koichiro Den <den@valinux.co.jp>
Subject: PCI: rcar-gen4: Recover the Root Port on link down

This patch adds handling for link down events on the R-Car PCIe controller.
It introduces a mechanism to defer Root Port recovery to a workqueue to
avoid host hangs from DBI accesses while the link is down. It also arms
this detection post-enumeration and disarms it during driver removal.

> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index 256410fb4b1cd..aa80232afabad 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
[ ... ]
> @@ -559,15 +575,35 @@ static int rcar_gen4_pcie_host_msi_addr(struct dw_pcie_rp *pp, u32 *msi_addr)
>  static void rcar_gen4_pcie_app_irq_sync_locked(struct rcar_gen4_pcie *rcar)
>  {
[ ... ]
> +	/*
> +	 * Note that rcar->rp_events_armed is not checked here because device
> +	 * removal may still need iMSI-RX interrupts after Root Port events have
> +	 * been disarmed.
> +	 */
>  	if (!rcar->reinit_pending && pp->use_imsi_rx && pci_msi_enabled())
>  		val |= MSI_CTRL_INT;
>  	writel(val, rcar->base + PCIEINTSTS0EN);
[ ... ]
> @@ -630,6 +666,44 @@ static int rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
[ ... ]
> +static void rcar_gen4_pcie_link_down_work(struct work_struct *work)
> +{
> +	struct rcar_gen4_pcie *rcar =
> +		container_of(work, struct rcar_gen4_pcie, link_down_work);
> +	struct pci_dev *port;
> +
> +	/* Hold a reference: the Root Port can be removed through sysfs. */
> +	port = pci_get_slot(rcar->dw.pp.bridge->bus, PCI_DEVFN(0, 0));
> +	if (!port)
> +		return;

[Severity: Medium]
If the Root Port has been removed via sysfs and pci_get_slot() returns NULL,
does this early return leave reinit_pending set to true?

Since rcar_gen4_pcie_handle_link_down() sets reinit_pending to true before
scheduling this work, bypassing the reset sequence here would fail to clear
reinit_pending. Could this result in MSI interrupts being permanently masked?

> +
> +	pci_host_handle_link_down(port);
> +	pci_dev_put(port);
> +}
[ ... ]
> @@ -640,6 +714,10 @@ static irqreturn_t rcar_gen4_pcie_msi_irq_handler(int irq, void *data)
[ ... ]
> +	/* Check reset requests before MSI handling, which accesses DBI. */
> +	if (rcar_gen4_pcie_handle_link_down(rcar))
> +		return IRQ_HANDLED;
> +
>  	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;
>  }
[ ... ]
> @@ -918,6 +1023,8 @@ static int rcar_gen4_add_dw_pcie_rp(struct rcar_gen4_pcie *rcar)
[ ... ]
>  static void rcar_gen4_remove_dw_pcie_rp(struct rcar_gen4_pcie *rcar)
>  {
> +	/* Cancel recovery work before removing the PCI bus */
> +	rcar_gen4_pcie_rp_events_disarm(rcar);
>  	dw_pcie_host_deinit(&rcar->dw.pp);
>  }

[Severity: High]
During host teardown, rcar_gen4_pcie_rp_events_disarm() is called which leaves
MSI interrupts enabled via rcar_gen4_pcie_app_irq_sync_locked().

The teardown then continues into the core:

drivers/pci/controller/dwc/pcie-designware-host.c:dw_pcie_host_deinit() {
    ...
    if (pp->use_imsi_rx)
        dw_pcie_free_msi(pp);

    if (pp->ops->deinit)
        pp->ops->deinit(pp);
    ...
}

Because dw_pcie_free_msi() frees the irq_domain before the driver's .deinit
callback has a chance to call free_irq(), what happens if a hardware
interrupt fires in this window?

Would rcar_gen4_pcie_msi_irq_handler() execute and call dw_handle_msi_irq(),
leading to a use-after-free when it dereferences the freed pp->irq_domain?

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