Re: [PATCH v2 1/3] mtd: spi-nor: fix the lock left held by spi_nor_rww_start_exclusive()

[Miquel Raynal]

On 14/09/2026 at 11:11:47 +03, Itai Handler <itai.handler@xxxxxxxxx> wrote:

> 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@xxxxxxxxxxxxxxx
> Signed-off-by: Itai Handler <itai.handler@xxxxxxxxx>

Michael, since we already got a cycle with AI walls of text just to tell
"fix that damn conversion", can I (or you) apply that other patch, so we
can get rid of these? Let me know what you prefer, although I don't
remember where that thread is.

Miquèl