All of lore.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Jianqiang kang <jianqkang@sina.cn>
Cc: gregkh@linuxfoundation.org, stable@vger.kernel.org,
	 patches@lists.linux.dev, linux-kernel@vger.kernel.org,
	thierry.reding@gmail.com,  jonathanh@nvidia.com,
	skomatineni@nvidia.com, ldewangan@nvidia.com, treding@nvidia.com,
	 broonie@kernel.org, va@nvidia.com, linux-tegra@vger.kernel.org,
	 linux-spi@vger.kernel.org
Subject: Re: [PATCH 6.12.y] spi: tegra210-quad: Protect curr_xfer check in IRQ handler
Date: Wed, 25 Mar 2026 04:12:42 -0700	[thread overview]
Message-ID: <acPDE9gBWneJWMn0@gmail.com> (raw)
In-Reply-To: <20260324060832.724228-1-jianqkang@sina.cn>

On Tue, Mar 24, 2026 at 02:08:32PM +0800, Jianqiang kang wrote:
> From: Breno Leitao <leitao@debian.org>
> 
> [ Upstream commit edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e ]
> 
> Now that all other accesses to curr_xfer are done under the lock,
> protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the
> spinlock. Without this protection, the following race can occur:
> 
>   CPU0 (ISR thread)              CPU1 (timeout path)
>   ----------------               -------------------
>   if (!tqspi->curr_xfer)
>     // sees non-NULL
>                                  spin_lock()
>                                  tqspi->curr_xfer = NULL
>                                  spin_unlock()
>   handle_*_xfer()
>     spin_lock()
>     t = tqspi->curr_xfer  // NULL!
>     ... t->len ...        // NULL dereference!
> 
> With this patch, all curr_xfer accesses are now properly synchronized.
> 
> Although all accesses to curr_xfer are done under the lock, in
> tegra_qspi_isr_thread() it checks for NULL, releases the lock and
> reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer().
> There is a potential for an update in between, which could cause a NULL
> pointer dereference.
> 
> To handle this, add a NULL check inside the handlers after acquiring
> the lock. This ensures that if the timeout path has already cleared
> curr_xfer, the handler will safely return without dereferencing the
> NULL pointer.
> 
> Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling")
> Signed-off-by: Breno Leitao <leitao@debian.org>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> Acked-by: Jon Hunter <jonathanh@nvidia.com>
> Acked-by: Thierry Reding <treding@nvidia.com>
> Link: https://patch.msgid.link/20260126-tegra_xfer-v2-6-6d2115e4f387@debian.org
> Signed-off-by: Mark Brown <broonie@kernel.org>
> [ Minor conflict resolved. ]
> Signed-off-by: Jianqiang kang <jianqkang@sina.cn>

Acked-by: Breno Leitao <leitao@debian.org>

  reply	other threads:[~2026-03-25 11:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24  6:08 [PATCH 6.12.y] spi: tegra210-quad: Protect curr_xfer check in IRQ handler Jianqiang kang
2026-03-25 11:12 ` Breno Leitao [this message]
2026-03-31 10:55 ` Patch "spi: tegra210-quad: Protect curr_xfer check in IRQ handler" has been added to the 6.12-stable tree gregkh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acPDE9gBWneJWMn0@gmail.com \
    --to=leitao@debian.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jianqkang@sina.cn \
    --cc=jonathanh@nvidia.com \
    --cc=ldewangan@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=skomatineni@nvidia.com \
    --cc=stable@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=treding@nvidia.com \
    --cc=va@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.