Re: [PATCH 2/3] dmaengine: plx_dma: Remove obsolete 32-bit DMA mask fallback

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Potential NULL pointer dereference in plx_dma_isr() because the interrupt handler is registered before plxdev->bar is initialized.
--

commit ebe0c3fecaf3a5fe091d793b49cde50217868ab8
Author: Ruizhe Zhou <zhouruizhe@resnics.com>

dmaengine: plx_dma: Remove obsolete 32-bit DMA mask fallback

The DMA API guarantees support for masks of 32 bits or wider. This commit
removes the obsolete 32-bit DMA mask fallback while retaining the error
check so that a genuine DMA setup failure is still propagated.

> diff --git a/drivers/dma/plx_dma.c b/drivers/dma/plx_dma.c
> index 84941a918b01f..ad9187448ed20 100644
> --- a/drivers/dma/plx_dma.c
> +++ b/drivers/dma/plx_dma.c
> @@ -562,8 +562,6 @@ static int plx_dma_probe(struct pci_dev *pdev,
>  		return rc;
>  
>  	rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(48));
> -	if (rc)
> -		rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
>  	if (rc)
>  		return rc;
>  

[Severity: High]
This is a pre-existing issue, but is there a potential NULL pointer
dereference in plx_dma_isr() due to the order of initialization in
plx_dma_create()?

When plx_dma_probe() calls plx_dma_create(), the interrupt handler is
registered before plxdev->bar is initialized:

drivers/dma/plx_dma.c:plx_dma_create() {
    ...
    rc = request_irq(pci_irq_vector(pdev, 0), plx_dma_isr, 0,
                     KBUILD_MODNAME, plxdev);
    if (rc)
        goto free_plx;

    ...
    plxdev->bar = pcim_iomap_table(pdev)[0];
    ...
}

If an interrupt triggers immediately after request_irq() (e.g., from a
spurious interrupt or a pending interrupt left by a previous kernel/kexec),
the handler will execute:

drivers/dma/plx_dma.c:plx_dma_isr() {
    ...
    status = readw(plxdev->bar + PLX_REG_INTR_STATUS);
    ...
}

Since plxdev is zero-allocated and plxdev->bar is initialized only after
the IRQ is registered, could this cause a kernel panic due to a NULL
pointer dereference? Should the driver state be fully initialized before
unmasking the interrupt?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903115441.912500-1-zhouruizhe@resnics.com?part=2