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

[Mark Brown]

On Tue, May 26, 2026 at 02:18:39AM +0000, Yang, Peng wrote:

> Hi Mark,

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> The race I'm fixing is specifically about the local variable “max” in
> dw_reader()/dw_writer(). These functions snapshot the FIFO level into
> a local “max" via dw_spi_rx_max()/dw_spi_tx_max(), then iterate

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

> Regarding irq_status being read before the lock: this is intentional.
> irq_status only gates which code path is taken (read vs write). The
> actual safety comes from the FIFO level check inside
> dw_spi_rx_max()/dw_spi_tx_max() being protected by the lock together
> with the DR access.

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.  That's also already an
issue, but it's complicated by the thin locking windows.

Attachment: signature.asc
Description: PGP signature