From: Itai Handler <itai.handler@gmail.com>
To: mwalle@kernel.org, pratyush@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
vigneshr@ti.com, richard@nod.at, miquel.raynal@bootlin.com,
takahiro.kuwano@infineon.com,
Itai Handler <itai.handler@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH v2 1/3] mtd: spi-nor: fix the lock left held by spi_nor_rww_start_exclusive()
Date: Mon, 14 Sep 2026 11:11:47 +0300 [thread overview]
Message-ID: <20260914081149.1916589-2-itai.handler@gmail.com> (raw)
In-Reply-To: <20260914081149.1916589-1-itai.handler@gmail.com>
spi_nor_rww_start_exclusive() takes nor->lock and never drops it. It
returns with the mutex held whether it hands out the exclusive claim or
reports the flash busy, leaving the caller holding a lock it does not
know it has.
Commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup
helpers") turned its "goto busy" into a plain "return false" and deleted
the busy: label that did the mutex_unlock(), but kept the mutex_lock()
at the top instead of replacing it with guard(mutex). It is now the only
one of the ten spi_nor_rww_{start,end}_* helpers that does not use the
guard.
Its only caller is spi_nor_prep_and_lock(), so on a flash with
SNOR_F_RWW set:
- if the flash is idle it returns true with nor->lock held, and the
matching spi_nor_unlock_and_unprep() calls
spi_nor_rww_end_exclusive(), whose guard(mutex)(&nor->lock) then
deadlocks on the non-recursive mutex;
- if the flash is busy it returns false with nor->lock held, and
wait_event_killable() sleeps holding it, so the operation that would
clear ongoing_* can never take the lock to do so.
Nothing reaches this today: the only flash with SPI_NOR_RWW is the
MX25UW51245G, which has neither OTP nor locking ops, so none of the
existing spi_nor_prep_and_lock() callers in otp.c, swp.c and sst.c apply
to it. It becomes reachable as soon as any common path takes the
exclusive lock.
Use guard(mutex) as the other helpers do.
Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
Cc: stable@vger.kernel.org
Signed-off-by: Itai Handler <itai.handler@gmail.com>
---
drivers/mtd/spi-nor/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ccf4396cdcd0..8bc117b46e02 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1310,7 +1310,7 @@ static bool spi_nor_rww_start_exclusive(struct spi_nor *nor)
{
struct spi_nor_rww *rww = &nor->rww;
- mutex_lock(&nor->lock);
+ guard(mutex)(&nor->lock);
if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe)
return false;
--
2.34.1
WARNING: multiple messages have this Message-ID (diff)
From: Itai Handler <itai.handler@gmail.com>
To: mwalle@kernel.org, pratyush@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
vigneshr@ti.com, richard@nod.at, miquel.raynal@bootlin.com,
takahiro.kuwano@infineon.com,
Itai Handler <itai.handler@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH v2 1/3] mtd: spi-nor: fix the lock left held by spi_nor_rww_start_exclusive()
Date: Mon, 14 Sep 2026 11:11:47 +0300 [thread overview]
Message-ID: <20260914081149.1916589-2-itai.handler@gmail.com> (raw)
In-Reply-To: <20260914081149.1916589-1-itai.handler@gmail.com>
spi_nor_rww_start_exclusive() takes nor->lock and never drops it. It
returns with the mutex held whether it hands out the exclusive claim or
reports the flash busy, leaving the caller holding a lock it does not
know it has.
Commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup
helpers") turned its "goto busy" into a plain "return false" and deleted
the busy: label that did the mutex_unlock(), but kept the mutex_lock()
at the top instead of replacing it with guard(mutex). It is now the only
one of the ten spi_nor_rww_{start,end}_* helpers that does not use the
guard.
Its only caller is spi_nor_prep_and_lock(), so on a flash with
SNOR_F_RWW set:
- if the flash is idle it returns true with nor->lock held, and the
matching spi_nor_unlock_and_unprep() calls
spi_nor_rww_end_exclusive(), whose guard(mutex)(&nor->lock) then
deadlocks on the non-recursive mutex;
- if the flash is busy it returns false with nor->lock held, and
wait_event_killable() sleeps holding it, so the operation that would
clear ongoing_* can never take the lock to do so.
Nothing reaches this today: the only flash with SPI_NOR_RWW is the
MX25UW51245G, which has neither OTP nor locking ops, so none of the
existing spi_nor_prep_and_lock() callers in otp.c, swp.c and sst.c apply
to it. It becomes reachable as soon as any common path takes the
exclusive lock.
Use guard(mutex) as the other helpers do.
Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
Cc: stable@vger.kernel.org
Signed-off-by: Itai Handler <itai.handler@gmail.com>
---
drivers/mtd/spi-nor/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ccf4396cdcd0..8bc117b46e02 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1310,7 +1310,7 @@ static bool spi_nor_rww_start_exclusive(struct spi_nor *nor)
{
struct spi_nor_rww *rww = &nor->rww;
- mutex_lock(&nor->lock);
+ guard(mutex)(&nor->lock);
if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe)
return false;
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-09-14 8:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 8:11 [PATCH v2 0/3] mtd: spi-nor: fix the unlocked restore on shutdown and remove Itai Handler
2026-09-14 8:11 ` Itai Handler
2026-09-14 8:11 ` Itai Handler [this message]
2026-09-14 8:11 ` [PATCH v2 1/3] mtd: spi-nor: fix the lock left held by spi_nor_rww_start_exclusive() Itai Handler
2026-09-14 8:22 ` sashiko-bot
2026-09-14 8:22 ` sashiko-bot
2026-09-14 12:09 ` Miquel Raynal
2026-09-14 12:09 ` Miquel Raynal
2026-09-14 12:20 ` Michael Walle
2026-09-14 12:20 ` Michael Walle
2026-09-14 12:34 ` Miquel Raynal
2026-09-14 12:34 ` Miquel Raynal
2026-09-14 12:41 ` Michael Walle
2026-09-14 12:41 ` Michael Walle
2026-09-14 13:11 ` Miquel Raynal
2026-09-14 13:11 ` Miquel Raynal
2026-09-14 8:11 ` [PATCH v2 2/3] mtd: spi-nor: take the flash lock in spi_nor_shutdown() Itai Handler
2026-09-14 8:11 ` Itai Handler
2026-09-14 8:24 ` sashiko-bot
2026-09-14 8:24 ` sashiko-bot
2026-09-14 12:15 ` Miquel Raynal
2026-09-14 12:15 ` Miquel Raynal
2026-09-14 8:11 ` [PATCH v2 3/3] mtd: spi-nor: take the flash lock in spi_nor_remove() Itai Handler
2026-09-14 8:11 ` Itai Handler
2026-09-14 8:26 ` sashiko-bot
2026-09-14 8:26 ` sashiko-bot
2026-09-14 12:19 ` Miquel Raynal
2026-09-14 12:19 ` Miquel Raynal
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=20260914081149.1916589-2-itai.handler@gmail.com \
--to=itai.handler@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--cc=takahiro.kuwano@infineon.com \
--cc=vigneshr@ti.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.