Re: [PATCH RFC v3 5/5] misc: Add edu_srpoc surprise removal POC driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] misc: missing reinit_completion() in edu_remove() causes unhandled IRQ storm
--

commit f9ed797f2f520a59d9e2c04ca2421e2d89d85acb
Author: Abhin Parekadan Jose <abhinjoses@gmail.com>

misc: Add edu_srpoc surprise removal POC driver

This commit adds a test driver for the QEMU edu device to reproduce
a surprise removal hang. The driver's remove callback schedules a
delayed interrupt and blocks until it fires or a disconnect work runs.

Link: https://lore.kernel.org/all/20260905183905.997833-4-abhinjoses@gmail.com/
Link: https://lore.kernel.org/all/20260905185027.291191F00A3A@smtp.kernel.org/

> diff --git a/drivers/misc/edu_srpoc.c b/drivers/misc/edu_srpoc.c
> new file mode 100644
> index 0000000000000..b74a95109dba9
> --- /dev/null
> +++ b/drivers/misc/edu_srpoc.c
[ ... ]
> +static void edu_remove(struct pci_dev *pdev)
> +{
> +	struct edu_dev *edu = pci_get_drvdata(pdev);
> +
> +	iowrite32(EDU_STATUS_IRQFACT, edu->regs + EDU_REG_STATUS);
> +	iowrite32(600000, edu->regs + EDU_REG_DELAYED_IRQ);
> +
> +	dev_info(&pdev->dev, "Waiting for IRQ in remove()\n");
> +	wait_for_completion(&edu->irq_done);

[Severity: Medium]
Could this leave an unhandled interrupt pending if the completion count was
already incremented?

If a prior interrupt (for example, from a previous test run or device state
before the driver loaded) has already called complete(&edu->irq_done),
wait_for_completion() will return immediately instead of waiting for the
600-second delayed interrupt requested just above.

This would allow edu_remove() to finish and the driver to unload while the
delayed hardware interrupt remains pending. When this interrupt fires later
with no handler registered, it could trigger an unhandled IRQ storm that
permanently disables the shared PCI INTx line, potentially affecting other
devices.

Should there be a call to reinit_completion(&edu->irq_done) before
requesting the delayed interrupt here?

> +	dev_info(&pdev->dev, "Unblocked, cleaning up\n");
> +
> +	pci_clear_disconnect_work(pdev);
> +	free_irq(pci_irq_vector(pdev, 0), edu);
> +	pci_free_irq_vectors(pdev);
> +	pci_clear_master(pdev);
> +	pci_iounmap(pdev, edu->regs);
> +	pci_release_regions(pdev);
> +	pci_disable_device(pdev);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260927175203.928270-1-abhinjoses@gmail.com?part=5