Re: [PATCH v2 2/2] spi: fsl-lpspi: fix missing RX DMA termination on TX prepare failure

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The early error return paths in `fsl_lpspi_dma_transfer()` fail to call `fsl_lpspi_reset()`, leaving the SPI controller enabled with active DMA requests and stale FIFO contents.
- [High] A race condition between asynchronous target aborts and transfer preparation can lead to lost abort signals and indefinite task hangs.
--

commit 28e337398d010b76ae512c9b76eaed6b301c616f
Author: Carlos Song <carlos.song@nxp.com>

spi: fsl-lpspi: fix missing RX DMA termination on TX prepare failure

This commit addresses a potential memory corruption or use-after-free issue
when the TX DMA descriptor fails to prepare. It ensures the RX DMA channel
is also appropriately terminated before returning an error.

> diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
> index 1a94a42fac319..906892453a843 100644
> --- a/drivers/spi/spi-fsl-lpspi.c
> +++ b/drivers/spi/spi-fsl-lpspi.c
> @@ -647,6 +647,7 @@ static int fsl_lpspi_dma_transfer(struct spi_controller *controller,
>  				tx->sgl, tx->nents, DMA_MEM_TO_DEV,
>  				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
>  	if (!desc_tx) {
> +		dmaengine_terminate_sync(controller->dma_rx);
>  		dmaengine_terminate_sync(controller->dma_tx);
>  		return -EINVAL;

[Severity: High]
This is a pre-existing issue, but does this error path leave the SPI
controller enabled and out of sync?

Prior to calling fsl_lpspi_dma_transfer(), the driver executes
fsl_lpspi_set_cmd() and fsl_lpspi_setup_transfer(). These enable the
SPI module and DMA requests, pushing a command word into the TX FIFO.

If dmaengine_prep_slave_sg() fails for the TX descriptor, we terminate the
DMA channels and return -EINVAL. The caller propagates this error to the
SPI core, but since the spi-fsl-lpspi driver does not implement the
handle_err() callback, the hardware is never reset by the core.

Since fsl_lpspi_reset() is bypassed here, the SPI module remains
enabled. Could subsequent transfers fail or corrupt data, making the
SPI controller unusable until the driver is unbound or the system reboots?

[Severity: High]
This isn't a bug introduced by this patch, but does the transfer preparation
sequence have a race condition with asynchronous target aborts?

fsl_lpspi_target_abort() can be called asynchronously by the SPI target
protocol driver to cancel an ongoing transfer, which sets
target_aborted to true and signals the completion structures.

Shortly after the DMA descriptor preparation shown above, the driver
calls reinit_completion() and unconditionally sets target_aborted to false:

fsl_lpspi_dma_transfer() {
        ...
        reinit_completion(&fsl_lpspi->dma_tx_completion);
        dma_async_issue_pending(controller->dma_tx);

        fsl_lpspi->target_aborted = false;
        ...
}

If fsl_lpspi_target_abort() executes just before these variables are reset,
the completion wakeup count is overwritten to 0 and the abort flag is
cleared.

Since target mode transfers use wait_for_completion_interruptible() without
a timeout, would the SPI worker thread block indefinitely waiting for a
transfer that the master has already aborted?

>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520094308.2882892-1-carlos.song@oss.nxp.com?part=2