Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Walle" <mwalle@kernel.org>
To: "Runyu Xiao" <runyu.xiao@seu.edu.cn>, <tudor.ambarus@linaro.org>
Cc: <pratyush@kernel.org>, <miquel.raynal@bootlin.com>,
	<richard@nod.at>, <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<jianhao.xu@seu.edu.cn>, <stable@vger.kernel.org>
Subject: Re: [PATCH] mtd: spi-nor: scope the exclusive RWW lock
Date: Mon, 10 Aug 2026 10:25:28 +0200	[thread overview]
Message-ID: <DKL4CBQNKCO2.3NAZ6S25Q60XN@kernel.org> (raw)
In-Reply-To: <20260809084223.3596259-1-runyu.xiao@seu.edu.cn>


[-- Attachment #1.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2026-08-10  8:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-09  8:42 [PATCH] mtd: spi-nor: scope the exclusive RWW lock Runyu Xiao
2026-08-10  8:25 ` Michael Walle [this message]
2026-08-10 12:47   ` Miquel Raynal
2026-08-11  4:13   ` [PATCH v2] " Runyu Xiao
2026-08-11  7:51     ` Miquel Raynal
2026-08-11  8:31     ` [PATCH v3] mtd: spi-nor: use guard() in spi_nor_rww_start_exclusive Runyu Xiao
2026-08-11  8:41       ` Miquel Raynal
2026-08-11 10:11       ` Tudor Ambarus
2026-08-11 10:42         ` Tudor Ambarus
2026-08-11 14:36           ` Miquel Raynal
2026-08-11 15:38             ` Miquel Raynal
2026-08-11  8:50     ` [PATCH v2] mtd: spi-nor: scope the exclusive RWW lock Michael Walle
2026-08-11 10:05   ` [PATCH] " Tudor Ambarus

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=DKL4CBQNKCO2.3NAZ6S25Q60XN@kernel.org \
    --to=mwalle@kernel.org \
    --cc=jianhao.xu@seu.edu.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=runyu.xiao@seu.edu.cn \
    --cc=stable@vger.kernel.org \
    --cc=tudor.ambarus@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox