[PATCH] mtd: spi-nor: scope the exclusive RWW lock

[PATCH] mtd: spi-nor: scope the exclusive RWW lock

[Runyu Xiao]

spi_nor_rww_start_exclusive() is used as a wait_event_killable()
condition. The raw mutex_lock() leaves nor->lock held when the busy
condition returns false, so the waiter can block the active operation that
must clear the RWW state.

Use the same scoped mutex guard as the other RWW start helpers so the
mutex is released on both the busy and successful condition paths. The
state flags remain the handoff to the caller, while
spi_nor_rww_end_exclusive() continues
to acquire the mutex when clearing them.

The change was checked by comparing the original and patched source.

A source-level check of the original wait condition found that it takes
`nor->lock` and returns false while an RWW operation is still active. The
patched source was checked for a scoped mutex guard that releases
`nor->lock` before the wait condition returns. A user-space pthread model
held `nor->lock` on the false-condition path and showed that the
operation-ending path then blocks when it needs the same mutex. No live
SPI-NOR test was run.

Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
 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

Re: [PATCH] mtd: spi-nor: scope the exclusive RWW lock

[Michael Walle]

[-- Attachment #1: Type: text/plain, Size: 2390 bytes --]

On Sun Aug 9, 2026 at 10:42 AM CEST, Runyu Xiao wrote:
> spi_nor_rww_start_exclusive() is used as a wait_event_killable()
> condition. The raw mutex_lock() leaves nor->lock held when the busy
> condition returns false, so the waiter can block the active operation that
> must clear the RWW state.
>
> Use the same scoped mutex guard as the other RWW start helpers so the
> mutex is released on both the busy and successful condition paths. The
> state flags remain the handoff to the caller, while
> spi_nor_rww_end_exclusive() continues
> to acquire the mutex when clearing them.
>
> The change was checked by comparing the original and patched source.

What do you mean? Was this AI assisted?

> A source-level check of the original wait condition found that it takes
> `nor->lock` and returns false while an RWW operation is still active. The
> patched source was checked for a scoped mutex guard that releases
> `nor->lock` before the wait condition returns. A user-space pthread model
> held `nor->lock` on the false-condition path and showed that the
> operation-ending path then blocks when it needs the same mutex. No live
> SPI-NOR test was run.

What do you mean by "user-space pthread model"? Ported this into
user-space and tried it there? Please keep the commit message
precise and don't use any AI gibberish. Please, explain what's going
on with your own sentences. That way, it shows at least some
understanding what you are trying to change here.

That being said, there is something odd about that commit. Tudor, do
you know why you've omitted the guard() in spi_nor_rww_start_exclusive()?

-michael

> Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> ---
>  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;


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

Re: [PATCH] mtd: spi-nor: scope the exclusive RWW lock

[Miquel Raynal]

Hello,

On 10/08/2026 at 10:25:28 +02, "Michael Walle" <mwalle@kernel.org> wrote:

> On Sun Aug 9, 2026 at 10:42 AM CEST, Runyu Xiao wrote:
>> spi_nor_rww_start_exclusive() is used as a wait_event_killable()
>> condition. The raw mutex_lock() leaves nor->lock held when the busy
>> condition returns false, so the waiter can block the active operation that
>> must clear the RWW state.
>>
>> Use the same scoped mutex guard as the other RWW start helpers so the
>> mutex is released on both the busy and successful condition paths. The
>> state flags remain the handoff to the caller, while
>> spi_nor_rww_end_exclusive() continues
>> to acquire the mutex when clearing them.
>>
>> The change was checked by comparing the original and patched source.
>
> What do you mean? Was this AI assisted?
>
>> A source-level check of the original wait condition found that it takes
>> `nor->lock` and returns false while an RWW operation is still active. The
>> patched source was checked for a scoped mutex guard that releases
>> `nor->lock` before the wait condition returns. A user-space pthread model
>> held `nor->lock` on the false-condition path and showed that the
>> operation-ending path then blocks when it needs the same mutex. No live
>> SPI-NOR test was run.
>
> What do you mean by "user-space pthread model"? Ported this into
> user-space and tried it there? Please keep the commit message
> precise and don't use any AI gibberish. Please, explain what's going
> on with your own sentences. That way, it shows at least some
> understanding what you are trying to change here.
>
> That being said, there is something odd about that commit. Tudor, do
> you know why you've omitted the guard() in
> spi_nor_rww_start_exclusive()?

I agree with Michael, the fix looks legitimate, however the commit log
is unreadable and should be a 3-line straightforward paragraph.

Thanks,
Miquèl

[PATCH v2] mtd: spi-nor: scope the exclusive RWW lock

[Runyu Xiao]

spi_nor_rww_start_exclusive() is used as the wait_event_killable()
condition for RWW access. When RWW is busy, it can return false while
still holding nor->lock, which blocks spi_nor_rww_end_exclusive() from
clearing the RWW state.

Use guard(mutex) here so nor->lock is released before the condition
returns, while the state flags still hand off ownership to the caller.
This keeps the mutex scope aligned with the other RWW start helpers.

Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
Changes in v2:
- Replace the analysis-style explanation with a short maintainer-facing
  description of the busy-path lock hold.
- Keep the fix focused on using guard(mutex) so the mutex is released on
  both paths.

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

Re: [PATCH v2] mtd: spi-nor: scope the exclusive RWW lock

[Miquel Raynal]

On 11/08/2026 at 12:13:49 +08, Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:

> spi_nor_rww_start_exclusive() is used as the wait_event_killable()
> condition for RWW access. When RWW is busy, it can return false while
> still holding nor->lock, which blocks spi_nor_rww_end_exclusive() from
> clearing the RWW state.
>
> Use guard(mutex) here so nor->lock is released before the condition
> returns, while the state flags still hand off ownership to the caller.
> This keeps the mutex scope aligned with the other RWW start helpers.

The diff is now correct, but the commit log is still missing the
point. There has been a translation from raw mutexes into scoped
helpers, this translation missed one spot. This should be the core of
your commit log.

Miquèl

[PATCH v3] mtd: spi-nor: use guard() in spi_nor_rww_start_exclusive

[Runyu Xiao]

Commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup
helpers") converted the RWW start helpers to scoped mutex cleanup, but
left spi_nor_rww_start_exclusive() using a plain mutex_lock().

spi_nor_rww_start_exclusive() is used as a wait_event_killable()
condition. When it returns false on the busy path, the raw mutex_lock()
leaves nor->lock held and blocks the operation that must clear the RWW
state in spi_nor_rww_end_exclusive().

Use guard(mutex) here as well so this helper matches the other RWW
start helpers and releases nor->lock on the false return path.

Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
Changes in v3:
- Reframe the changelog around the scoped-helper conversion that missed
  spi_nor_rww_start_exclusive().

Changes in v2:
- Replace the analysis-style explanation with a short maintainer-facing
  description of the busy-path lock hold.
- Keep the fix focused on using guard(mutex) so the mutex is released on
  both paths.

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

Re: [PATCH v3] mtd: spi-nor: use guard() in spi_nor_rww_start_exclusive

[Miquel Raynal]

On 11/08/2026 at 16:31:11 +08, Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:

> Commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup
> helpers") converted the RWW start helpers to scoped mutex cleanup, but
> left spi_nor_rww_start_exclusive() using a plain mutex_lock().
>
> spi_nor_rww_start_exclusive() is used as a wait_event_killable()
> condition. When it returns false on the busy path, the raw mutex_lock()
> leaves nor->lock held and blocks the operation that must clear the RWW
> state in spi_nor_rww_end_exclusive().
>
> Use guard(mutex) here as well so this helper matches the other RWW
> start helpers and releases nor->lock on the false return path.
>
> Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Re: [PATCH v3] mtd: spi-nor: use guard() in spi_nor_rww_start_exclusive

[Tudor Ambarus]

On 8/11/26 11:31 AM, Runyu Xiao wrote:
> Commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup
> helpers") converted the RWW start helpers to scoped mutex cleanup, but
> left spi_nor_rww_start_exclusive() using a plain mutex_lock().
> 
> spi_nor_rww_start_exclusive() is used as a wait_event_killable()
> condition. When it returns false on the busy path, the raw mutex_lock()
> leaves nor->lock held and blocks the operation that must clear the RWW
> state in spi_nor_rww_end_exclusive().
> 
> Use guard(mutex) here as well so this helper matches the other RWW
> start helpers and releases nor->lock on the false return path.
> 
> Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")

The fixes tag is wrong. The blamed commit did not change the functionality
of the code, while yours does.

You shall instead blame the commit that failed to release the lock in the
first place. But then if you want to have this backported to stable kernels
you may want to add 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex
cleanup helpers") as a prerequisite patch, as it includes <linux/cleanup.h>.

Cheers,
ta

> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> ---
> Changes in v3:
> - Reframe the changelog around the scoped-helper conversion that missed
>   spi_nor_rww_start_exclusive().
> 
> Changes in v2:
> - Replace the analysis-style explanation with a short maintainer-facing
>   description of the busy-path lock hold.
> - Keep the fix focused on using guard(mutex) so the mutex is released on
>   both paths.
> 
> 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;

Re: [PATCH v3] mtd: spi-nor: use guard() in spi_nor_rww_start_exclusive

[Tudor Ambarus]

Hi, Runyu, Miquel,

On 8/11/26 1:11 PM, Tudor Ambarus wrote:
> 
> 
> On 8/11/26 11:31 AM, Runyu Xiao wrote:
>> Commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup
>> helpers") converted the RWW start helpers to scoped mutex cleanup, but
>> left spi_nor_rww_start_exclusive() using a plain mutex_lock().
>>
>> spi_nor_rww_start_exclusive() is used as a wait_event_killable()
>> condition. When it returns false on the busy path, the raw mutex_lock()
>> leaves nor->lock held and blocks the operation that must clear the RWW
>> state in spi_nor_rww_end_exclusive().
>>
>> Use guard(mutex) here as well so this helper matches the other RWW
>> start helpers and releases nor->lock on the false return path.
>>
>> Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
> 
> The fixes tag is wrong. The blamed commit did not change the functionality
> of the code, while yours does.
> 
> You shall instead blame the commit that failed to release the lock in the
> first place. But then if you want to have this backported to stable kernels
> you may want to add 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex
> cleanup helpers") as a prerequisite patch, as it includes <linux/cleanup.h>.
> 

Runyu, please also update the commit subject, the point of the patch is
that it fixes a mutex leak, thus I suggest to reword it with something like
"mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive()"

>> Cc: stable@vger.kernel.org
>> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
>> ---
>> Changes in v3:
>> - Reframe the changelog around the scoped-helper conversion that missed
>>   spi_nor_rww_start_exclusive().
>>
>> Changes in v2:
>> - Replace the analysis-style explanation with a short maintainer-facing
>>   description of the busy-path lock hold.
>> - Keep the fix focused on using guard(mutex) so the mutex is released on
>>   both paths.
>>
>> 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);
>>  

Miquel,

Have you seen sashiko's review at 
https://sashiko.dev/#/patchset/20260811083111.403453-1-runyu.xiao%40seu.edu.cn?

Both concerns look valid to me. Do you think you can allocate time to fix them?

Cheers,
ta

>>  	if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe)
>>  		return false;
> 

Re: [PATCH v3] mtd: spi-nor: use guard() in spi_nor_rww_start_exclusive

[Miquel Raynal]

> Miquel,
>
> Have you seen sashiko's review at 
> https://sashiko.dev/#/patchset/20260811083111.403453-1-runyu.xiao%40seu.edu.cn?
>
> Both concerns look valid to me. Do you think you can allocate time to
> fix them?

Sashiko is becoming a nightmare. I'll add this to my todo list, but if
someone in lack of technical challenge wants to propose fixes, be my
guest.

Thanks,
Miquèl

Re: [PATCH v3] mtd: spi-nor: use guard() in spi_nor_rww_start_exclusive

[Miquel Raynal]

>> Have you seen sashiko's review at 
>> https://sashiko.dev/#/patchset/20260811083111.403453-1-runyu.xiao%40seu.edu.cn?
>>
>> Both concerns look valid to me. Do you think you can allocate time to
>> fix them?
>
> Sashiko is becoming a nightmare. I'll add this to my todo list, but if
> someone in lack of technical challenge wants to propose fixes, be my
> guest.

Actually, the might_sleep() warning seems to be an hallucination. It
mixes different concepts in its explanation (might_sleep() is not a
problem here, we are in process context) and I believe it got mislead by
the current state of the code which lacks a mutex_unlock(). The second
issue is definitely not "high" and only touches legacy
spi-nor-controllers. This is worth fixing though.

Thanks,
Miquèl

Re: [PATCH v2] mtd: spi-nor: scope the exclusive RWW lock

[Michael Walle]

Hi,

On Tue Aug 11, 2026 at 6:13 AM CEST, Runyu Xiao wrote:
> spi_nor_rww_start_exclusive() is used as the wait_event_killable()
> condition for RWW access. When RWW is busy, it can return false while
> still holding nor->lock, which blocks spi_nor_rww_end_exclusive() from
> clearing the RWW state.
>
> Use guard(mutex) here so nor->lock is released before the condition
> returns, while the state flags still hand off ownership to the caller.
> This keeps the mutex scope aligned with the other RWW start helpers.
>
> Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>

There were questions in v1. Please answer them. Don't just ignore
them and just throw a new version of your patch at us. We put time
and effort into maintaining. See also [1].

-michael

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Re: [PATCH] mtd: spi-nor: scope the exclusive RWW lock

[Tudor Ambarus]

On 8/10/26 11:25 AM, Michael Walle wrote:
> Tudor, do
> you know why you've omitted the guard() in spi_nor_rww_start_exclusive()?

because using guard changes the behavior of the code.