[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aWoiFebhTHbYibQO@orome>
Date: Fri, 16 Jan 2026 12:38:43 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Breno Leitao <leitao@...ian.org>
Cc: Jonathan Hunter <jonathanh@...dia.com>,
Sowjanya Komatineni <skomatineni@...dia.com>, Laxman Dewangan <ldewangan@...dia.com>,
Mark Brown <broonie@...nel.org>, Vishwaroop A <va@...dia.com>,
Thierry Reding <treding@...dia.com>, linux-tegra@...r.kernel.org, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-team@...a.com, puranjay@...nel.org,
usamaarif642@...il.com
Subject: Re: [PATCH 2/6] spi: tegra210-quad: Move curr_xfer read inside
spinlock
On Fri, Jan 16, 2026 at 02:41:42AM -0800, Breno Leitao wrote:
> Move the assignment of the transfer pointer from curr_xfer inside the
> spinlock critical section in both handle_cpu_based_xfer() and
> handle_dma_based_xfer().
>
> Previously, curr_xfer was read before acquiring the lock, creating a
> window where the timeout path could clear curr_xfer between reading it
> and using it. By moving the read inside the lock, the handlers are
> guaranteed to see a consistent value that cannot be modified by the
> timeout path.
>
> Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
> Signed-off-by: Breno Leitao <leitao@...ian.org>
> ---
> drivers/spi/spi-tegra210-quad.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
I think this is the root problem of one of the crashes that were
reported. The problem seems to be that the high CPU load can lead to a
case where tqspi->curr_xfer is modified after being copied to the local
variable, and before the check. The window for this is very slim for the
CPU based transfer, but for DMA based transfers I can see that happening
more easily.
Acked-by: Thierry Reding <treding@...dia.com>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists