| Message ID | 20260827082656.2772784-1-runyu.xiao@seu.edu.cn |
|---|---|
| State | New |
| Headers | show |
| Series | [v5] mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive() | expand |
On 27/08/2026 at 16:26:56 +08, Runyu Xiao <runyu.xiao@seu.edu.cn> wrote: > spi_nor_rww_start_exclusive() is used as a wait_event_killable() > condition. When an RWW operation is already in progress, it returns > false while still holding nor->lock. The wait condition is then retried, > but spi_nor_rww_end_exclusive() needs the same lock to clear the RWW > state, so the wait can deadlock. This paragraph is a bit irrelevant, we don't really care about the feature itself: there was a conversion to scoped mutexes, this conversion missed one place, you fix it. That is the justification, but fine, let's stop iterating on such a trivial fix. > Use the same guard(mutex) pattern as the other RWW helpers so nor->lock > is released on both the busy and successful return paths. > > 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> Didn't I send a Reviewed-by tag already? Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Miquèl
On Thu, 27 Aug 2026 at 10:33:03 +0200, Miquel Raynal wrote: > This paragraph is a bit irrelevant, we don't really care about the > feature itself: there was a conversion to scoped mutexes, this > conversion missed one place, you fix it. That is the justification, but > fine, let's stop iterating on such a trivial fix. > > Didn't I send a Reviewed-by tag already? > > Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Thanks for the clarification. I agree that the commit message should focus on the scoped-mutex conversion missing spi_nor_rww_start_exclusive(), rather than explain the RWW feature itself. Sorry for the extra iterations and for missing your Reviewed-by tag from the earlier thread. Since v5 is already sent, I will not send another revision just to add the tag; I have noted it for the patch application. Thanks, Runyu
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;
spi_nor_rww_start_exclusive() is used as a wait_event_killable() condition. When an RWW operation is already in progress, it returns false while still holding nor->lock. The wait condition is then retried, but spi_nor_rww_end_exclusive() needs the same lock to clear the RWW state, so the wait can deadlock. Use the same guard(mutex) pattern as the other RWW helpers so nor->lock is released on both the busy and successful return paths. 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 v5: - Drop the interrupted-wait cleanup patch because an equivalent fix is already pending upstream. - Restore the focused guard(mutex) change for the exclusive RWW helper. - Restore the original Fixes tag and keep the other RWW helpers unchanged. Changes in v4: - Add the interrupted-wait cleanup as a separate patch. - Convert all RWW start helpers used as wait conditions to conditional scoped mutex guards. - Update the subject and change the Fixes tag while reworking the patch. Changes in v3: - Use guard(mutex) in spi_nor_rww_start_exclusive() so the lock is released on both return paths. - Update the subject to describe the guard-based fix. Changes in v2: - Explicitly unlock nor->lock before returning from the busy path. - Clarify the lock leak and its effect on the matching end helper. drivers/mtd/spi-nor/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)