[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 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.

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] mtd: spi-nor: scope the exclusive RWW lock

[Michael Walle]

On Tue Aug 11, 2026 at 12:05 PM CEST, Tudor Ambarus wrote:
>
>
> 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.

But that commit removed the mutex_unlock(), thus keeping the lock.
That wasn't the case before the commit. IMHO the Fixes: tag is
correct.

-michael

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

[Tudor Ambarus]

On 8/12/26 9:14 AM, Michael Walle wrote:
> On Tue Aug 11, 2026 at 12:05 PM CEST, Tudor Ambarus wrote:
>>
>>
>> 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.
> 
> But that commit removed the mutex_unlock(), thus keeping the lock.

oh, the horror, indeed.

> That wasn't the case before the commit. IMHO the Fixes: tag is
> correct.

+1

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")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>

Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>

> ---
> 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]

On 8/11/26 6:38 PM, Miquel Raynal wrote:
>>> 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().

I haven't tested but sashiko seems sane on this.

wait_event_killable()
  __wait_event_killable()
    ___wait_event(wq, condition, TASK_KILLABLE, 0, 0, schedule())  <- TASK_KILLABLE!

Here there's a for loop where it calls prepare_to_wait_event() which calls
set_current_state(TASK_KILLABLE), setting current->__state = TASK_KILLABLE and
storing the callsite in current->task_state_change.

After prepare_to_wait_event(), ___wait_event() evaluates condition
spi_nor_rww_start_exclusive(nor) which calls mutex_lock().
mutex_lock() calls might_sleep(). You hit the WARN_ONCE in __might_sleep() because
state == TASK_KILLABLE. You should catch this if you enable CONFIG_DEBUG_ATOMIC_SLEEP.

Cheers,
ta

[PATCH v4 0/2] mtd: spi-nor: core: Fix RWW wait locking

[Runyu Xiao]

The RWW wait helpers must not block while evaluating the wait
condition. In the current code, spi_nor_rww_start_exclusive() can leave
nor->lock held on a false return. Also, if a killable RWW wait is
interrupted after spi_nor_prep(), the controller setup must be undone.

Patch 1 switches the four RWW start helpers to conditional scoped mutex
guards so the wait condition never sleeps and the mutex is always
released before returning.
Patch 2 unprepares the controller on interrupted waits in the three
spi_nor_prep_and_lock() helpers.

Runyu Xiao (2):
  mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive()
  mtd: spi-nor: core: Unprepare after interrupted RWW wait

 drivers/mtd/spi-nor/core.c | 93 ++++++++++++++++++++++----------------
 1 file changed, 54 insertions(+), 39 deletions(-)

base-commit: 2b533e775aec580cf60074417f4ca00ac9cf3580
-- 
2.34.1

[PATCH v4 1/2] mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive()

[Runyu Xiao]

The RWW wait helpers must not block while evaluating the condition.
spi_nor_rww_start_exclusive() used mutex_lock() directly and could return
with nor->lock still held.

Switch the four RWW start helpers to conditional scoped mutex guards so
the wait condition never sleeps and nor->lock is released before return.

Fixes: 74df43b3f626 ("mtd: spi-nor: Enhance locking to support reads while writes")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>

Changes in v4:
- Use the original RWW locking commit in Fixes and update the subject.
- Apply the locking fix to all RWW start helpers used as wait conditions.
- Keep commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex
  cleanup helpers") as a stable prerequisite because it adds cleanup.h.
---
 drivers/mtd/spi-nor/core.c | 84 ++++++++++++++++++++------------------
 1 file changed, 45 insertions(+), 39 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ccf4396cdcd0..d5c6a925862e 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1273,14 +1273,15 @@ static bool spi_nor_rww_start_io(struct spi_nor *nor)
 {
 	struct spi_nor_rww *rww = &nor->rww;
 
-	guard(mutex)(&nor->lock);
-
-	if (rww->ongoing_io)
-		return false;
+	scoped_guard(mutex_try, &nor->lock) {
+		if (rww->ongoing_io)
+			return false;
 
-	rww->ongoing_io = true;
+		rww->ongoing_io = true;
+		return true;
+	}
 
-	return true;
+	return false;
 }
 
 static void spi_nor_rww_end_io(struct spi_nor *nor)
@@ -1310,16 +1311,17 @@ static bool spi_nor_rww_start_exclusive(struct spi_nor *nor)
 {
 	struct spi_nor_rww *rww = &nor->rww;
 
-	mutex_lock(&nor->lock);
-
-	if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe)
-		return false;
+	scoped_guard(mutex_try, &nor->lock) {
+		if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe)
+			return false;
 
-	rww->ongoing_io = true;
-	rww->ongoing_rd = true;
-	rww->ongoing_pe = true;
+		rww->ongoing_io = true;
+		rww->ongoing_rd = true;
+		rww->ongoing_pe = true;
+		return true;
+	}
 
-	return true;
+	return false;
 }
 
 static void spi_nor_rww_end_exclusive(struct spi_nor *nor)
@@ -1369,23 +1371,25 @@ static bool spi_nor_rww_start_pe(struct spi_nor *nor, loff_t start, size_t len)
 	u8 first, last;
 	int bank;
 
-	guard(mutex)(&nor->lock);
+	scoped_guard(mutex_try, &nor->lock) {
+		if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe)
+			return false;
 
-	if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe)
-		return false;
+		spi_nor_offset_to_banks(nor->params->bank_size, start, len,
+					&first, &last);
+		for (bank = first; bank <= last; bank++) {
+			if (rww->used_banks & BIT(bank))
+				return false;
 
-	spi_nor_offset_to_banks(nor->params->bank_size, start, len, &first, &last);
-	for (bank = first; bank <= last; bank++) {
-		if (rww->used_banks & BIT(bank))
-			return false;
+			used_banks |= BIT(bank);
+		}
 
-		used_banks |= BIT(bank);
+		rww->used_banks |= used_banks;
+		rww->ongoing_pe = true;
+		return true;
 	}
 
-	rww->used_banks |= used_banks;
-	rww->ongoing_pe = true;
-
-	return true;
+	return false;
 }
 
 static void spi_nor_rww_end_pe(struct spi_nor *nor, loff_t start, size_t len)
@@ -1440,24 +1444,26 @@ static bool spi_nor_rww_start_rd(struct spi_nor *nor, loff_t start, size_t len)
 	u8 first, last;
 	int bank;
 
-	guard(mutex)(&nor->lock);
+	scoped_guard(mutex_try, &nor->lock) {
+		if (rww->ongoing_io || rww->ongoing_rd)
+			return false;
 
-	if (rww->ongoing_io || rww->ongoing_rd)
-		return false;
+		spi_nor_offset_to_banks(nor->params->bank_size, start, len,
+					&first, &last);
+		for (bank = first; bank <= last; bank++) {
+			if (rww->used_banks & BIT(bank))
+				return false;
 
-	spi_nor_offset_to_banks(nor->params->bank_size, start, len, &first, &last);
-	for (bank = first; bank <= last; bank++) {
-		if (rww->used_banks & BIT(bank))
-			return false;
+			used_banks |= BIT(bank);
+		}
 
-		used_banks |= BIT(bank);
+		rww->used_banks |= used_banks;
+		rww->ongoing_io = true;
+		rww->ongoing_rd = true;
+		return true;
 	}
 
-	rww->used_banks |= used_banks;
-	rww->ongoing_io = true;
-	rww->ongoing_rd = true;
-
-	return true;
+	return false;
 }
 
 static void spi_nor_rww_end_rd(struct spi_nor *nor, loff_t start, size_t len)
-- 
2.34.1

[PATCH v4 2/2] mtd: spi-nor: core: Unprepare after interrupted RWW wait

[Runyu Xiao]

spi_nor_prep_and_lock() calls spi_nor_prep() before waiting. If the wait
is interrupted, the controller setup is left active.

Call spi_nor_unprep() before returning an error from each helper.

Fixes: 74df43b3f626 ("mtd: spi-nor: Enhance locking to support reads while writes")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>

Changes in v4:
- Add the cleanup for interrupted RWW waits as a separate patch.
- Use the original RWW locking commit in Fixes.
---
 drivers/mtd/spi-nor/core.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index d5c6a925862e..52264e24eb4b 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1348,6 +1348,9 @@ int spi_nor_prep_and_lock(struct spi_nor *nor)
 		ret = wait_event_killable(nor->rww.wait,
 					  spi_nor_rww_start_exclusive(nor));
 
+	if (ret)
+		spi_nor_unprep(nor);
+
 	return ret;
 }
 
@@ -1421,6 +1424,9 @@ static int spi_nor_prep_and_lock_pe(struct spi_nor *nor, loff_t start, size_t le
 		ret = wait_event_killable(nor->rww.wait,
 					  spi_nor_rww_start_pe(nor, start, len));
 
+	if (ret)
+		spi_nor_unprep(nor);
+
 	return ret;
 }
 
@@ -1496,6 +1502,9 @@ static int spi_nor_prep_and_lock_rd(struct spi_nor *nor, loff_t start, size_t le
 		ret = wait_event_killable(nor->rww.wait,
 					  spi_nor_rww_start_rd(nor, start, len));
 
+	if (ret)
+		spi_nor_unprep(nor);
+
 	return ret;
 }
 
-- 
2.34.1

Re: [PATCH v4 2/2] mtd: spi-nor: core: Unprepare after interrupted RWW wait

[Miquel Raynal]

Hi Runyu,

On 19/08/2026 at 22:03:37 +08, Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:

> spi_nor_prep_and_lock() calls spi_nor_prep() before waiting. If the wait
> is interrupted, the controller setup is left active.
>
> Call spi_nor_unprep() before returning an error from each helper.
>
> Fixes: 74df43b3f626 ("mtd: spi-nor: Enhance locking to support reads while writes")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
>
> Changes in v4:
> - Add the cleanup for interrupted RWW waits as a separate patch.
> - Use the original RWW locking commit in Fixes.

There is already a pending patch for that part:

https://lore.kernel.org/linux-mtd/87o6f7mzbq.fsf@bootlin.com/T/#m69e389f70eb3e34c0573bf289cb050825f14b516

Thanks,
Miquèl

Re: [PATCH v4 1/2] mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive()

[Miquel Raynal]

On 19/08/2026 at 22:03:36 +08, Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:

> The RWW wait helpers must not block while evaluating the condition.
> spi_nor_rww_start_exclusive() used mutex_lock() directly and could return
> with nor->lock still held.
>
> Switch the four RWW start helpers to conditional scoped mutex guards so
> the wait condition never sleeps and nor->lock is released before
> return.

What? Why?

Please.

Previous patch was right, why are you converting to scope guard?

You did not pick the Reviewed-by tags.
>
> Fixes: 74df43b3f626 ("mtd: spi-nor: Enhance locking to support reads
> while writes")

This Fixes is wrong, the original one was right, please check the entire
conversation.

> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
>
> Changes in v4:

Changelog should not be here but below the ---.

You miss changes from v2 and v3.

> - Use the original RWW locking commit in Fixes and update the subject.
> - Apply the locking fix to all RWW start helpers used as wait conditions.
> - Keep commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex
>   cleanup helpers") as a stable prerequisite because it adds
> cleanup.h.

Where did you do that?

If you want to fix the remaining Sashiko issue (the sleep issue) you
can, but please do it in another patch.

Thanks,
Miquèl