Re: [PATCH] spi: dw: fix race between transfer IRQ handler and timeout handler

[Peng Yang]

On Mon, May 26, 2026 at ..., Mark Brown wrote:
> Please don't top post, reply in line with needed context.

Apologies for the format, fixing it here.

> Please fix your mail client to word wrap within paragraphs at
> something substantially less than 80 columns.

Will do.

> That doesn't mean that's the only possible thing that could race.

I've traced through the code paths during my debug. The only
race path is in IRQ mode, where handle_err() calls
dw_spi_reset_chip() from the SPI core kthread while the IRQ
handler is still servicing FIFO interrupts on another CPU.

Poll mode returns 0 so the kthread never sleeps and
handle_err can't be reached concurrently.

DMA mode has its own transfer handler that doesn't access
the FIFO directly.

> What happens if between checking the interrupt status and
> handling the FIFOs we call dw_spi_handle_err()?  The next
> transfer could be started, updating the buffer pointers and
> lengths in dw_spi_transfer_one() but that doesn't exclude
> the interrupt handler.

Looking at spi_transfer_one_message(), handle_err() and the
next transfer_one() are called sequentially from the same
kthread:

  transfer_one() -> spi_transfer_wait() -> timeout ->
  handle_err() -> spi_finalize_current_message() ->
  next transfer_one()

A new transfer cannot start until handle_err() returns and
spi_finalize_current_message() completes, so buffer pointers
won't be updated concurrently.

If reset happens between checking irq_status and taking the
lock, dw_reader/dw_writer will see an empty FIFO (max=0)
and exit without accessing DR.

> That's also already an issue, but it's complicated by the
> thin locking windows.

I think this case is safe because the kthread serializes
handle_err and the next transfer_one sequentially, so the
buffer pointers can't be updated while the IRQ handler is
still running.

Please let me know if I'm missing something here.

Best Regards,
Peng Yang