Linux block layer
 help / color / mirror / Atom feed
* [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active
@ 2026-11-04 11:27 Stanley Jhu
  2026-11-04 14:34 ` Rafael J. Wysocki (Intel)
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Stanley Jhu @ 2026-11-04 11:27 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Bart Van Assche, Brian Norris, Rafael J . Wysocki, Praveen Talari,
	Alan Stern, linux-block, linux-pm, linux-scsi, linux-kernel,
	stable, Stanley Jhu

Since commit eef1d74bf88f ("PM: runtime: Only set runtime_error on
suspend callback failures"), a failed runtime resume leaves
dev->power.runtime_error at 0 with runtime_status set to RPM_SUSPENDED,
so later runtime resume requests run sdev_runtime_resume() again:

1. A runtime suspend increments q->pm_only from 0 to 1 and sets
   q->rpm_status to RPM_SUSPENDED.
2. The first runtime resume fails in the driver callback, and
   blk_post_runtime_resume() sets q->rpm_status to RPM_ACTIVE and calls
   blk_clear_pm_only(), decrementing q->pm_only from 1 to 0 so recovery
   commands can enter the queue (intended since
   commit 6e1fcab00a23 ("scsi: block: pm: Always set request queue
   runtime active in blk_post_runtime_resume()")).
3. A retried runtime resume calls blk_pre_runtime_resume(), which
   overwrites q->rpm_status from RPM_ACTIVE to RPM_RESUMING, so
   blk_post_runtime_resume() sees old_status != RPM_ACTIVE and calls
   blk_clear_pm_only() a second time without a matching
   blk_set_pm_only().
4. q->pm_only underflows from 0 to -1 (triggering WARN_ON_ONCE in
   blk_clear_pm_only()), blocking non-PM requests in blk_queue_enter()
   and __bio_queue_enter() while the device is RPM_ACTIVE, and the next
   runtime suspend increments q->pm_only from -1 to 0, letting non-PM
   requests dispatch while RPM_SUSPENDED. This hits the UFS device
   well-known LUN by default and SCSI disks with
   manage_runtime_start_stop enabled (ATA and FireWire sbp2 defaults).

Transition q->rpm_status to RPM_RESUMING in blk_pre_runtime_resume()
only when it is RPM_SUSPENDED, and call blk_clear_pm_only() in
blk_post_runtime_resume() only when old_status is RPM_RESUMING, pairing
each clear with a completed runtime suspend.

Tested on QEMU ARM64 UFS in SDB and MCQ modes by injecting
runtime-resume START STOP UNIT failures on the UFS device well-known
LUN, confirming zero pm_only underflows and balanced runtime PM cycles.

Fixes: eef1d74bf88f ("PM: runtime: Only set runtime_error on suspend callback failures")
Cc: stable@vger.kernel.org # v7.3+
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
---
Differences from v1:
- Move SUSPENDED -> RESUMING explicitly in blk_pre_runtime_resume() and
  clear pm_only only for RPM_RESUMING in blk_post_runtime_resume()
- Describe the QEMU UFS test coverage in the commit message
- Link to v1: https://lore.kernel.org/r/20261029040001.2100001-1-stanleyjhu@google.com

 block/blk-pm.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/block/blk-pm.c b/block/blk-pm.c
index 8d3e052f91da..34cc7c5ca04e 100644
--- a/block/blk-pm.c
+++ b/block/blk-pm.c
@@ -142,7 +142,8 @@ EXPORT_SYMBOL(blk_post_runtime_suspend);
  *
  * Description:
  *    Update the queue's runtime status to RESUMING in preparation for the
- *    runtime resume of the device.
+ *    runtime resume of the device if the queue is runtime suspended, or keep
+ *    RPM_ACTIVE if a previous failed runtime resume already reactivated it.
  *
  *    This function should be called near the start of the device's
  *    runtime_resume callback.
@@ -153,7 +154,9 @@ void blk_pre_runtime_resume(struct request_queue *q)
 		return;
 
 	spin_lock_irq(&q->queue_lock);
-	q->rpm_status = RPM_RESUMING;
+	/* Keep RPM_ACTIVE if a prior failed resume reactivated the queue. */
+	if (q->rpm_status == RPM_SUSPENDED)
+		q->rpm_status = RPM_RESUMING;
 	spin_unlock_irq(&q->queue_lock);
 }
 EXPORT_SYMBOL(blk_pre_runtime_resume);
@@ -168,8 +171,8 @@ EXPORT_SYMBOL(blk_pre_runtime_resume);
  *    driver or error handler will need to communicate with the device.
  *
  *    This function should be called near the end of the device's
- *    runtime_resume callback to correct queue runtime PM status and re-enable
- *    peeking requests from the queue.
+ *    runtime_resume callback to mark the queue runtime active and clear
+ *    pm_only if the queue was resuming.
  */
 void blk_post_runtime_resume(struct request_queue *q)
 {
@@ -185,7 +188,7 @@ void blk_post_runtime_resume(struct request_queue *q)
 	pm_request_autosuspend(q->dev);
 	spin_unlock_irq(&q->queue_lock);
 
-	if (old_status != RPM_ACTIVE)
+	if (old_status == RPM_RESUMING)
 		blk_clear_pm_only(q);
 }
 EXPORT_SYMBOL(blk_post_runtime_resume);
-- 
2.56.0.385.gac671c819a-goog


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active
  2026-11-04 11:27 [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active Stanley Jhu
@ 2026-11-04 14:34 ` Rafael J. Wysocki (Intel)
  2026-11-04 18:34 ` Bart Van Assche
  2026-11-08 10:11 ` shinichiro.kawasaki
  2 siblings, 0 replies; 7+ messages in thread
From: Rafael J. Wysocki (Intel) @ 2026-11-04 14:34 UTC (permalink / raw)
  To: Stanley Jhu
  Cc: Jens Axboe, Bart Van Assche, Brian Norris, Rafael J . Wysocki,
	Praveen Talari, Alan Stern, linux-block, linux-pm, linux-scsi,
	linux-kernel, stable

On Wed, Nov 4, 2026 at 12:27 PM Stanley Jhu <stanleyjhu@google.com> wrote:
>
> Since commit eef1d74bf88f ("PM: runtime: Only set runtime_error on
> suspend callback failures"), a failed runtime resume leaves
> dev->power.runtime_error at 0 with runtime_status set to RPM_SUSPENDED,
> so later runtime resume requests run sdev_runtime_resume() again:
>
> 1. A runtime suspend increments q->pm_only from 0 to 1 and sets
>    q->rpm_status to RPM_SUSPENDED.
> 2. The first runtime resume fails in the driver callback, and
>    blk_post_runtime_resume() sets q->rpm_status to RPM_ACTIVE and calls
>    blk_clear_pm_only(), decrementing q->pm_only from 1 to 0 so recovery
>    commands can enter the queue (intended since
>    commit 6e1fcab00a23 ("scsi: block: pm: Always set request queue
>    runtime active in blk_post_runtime_resume()")).
> 3. A retried runtime resume calls blk_pre_runtime_resume(), which
>    overwrites q->rpm_status from RPM_ACTIVE to RPM_RESUMING, so
>    blk_post_runtime_resume() sees old_status != RPM_ACTIVE and calls
>    blk_clear_pm_only() a second time without a matching
>    blk_set_pm_only().
> 4. q->pm_only underflows from 0 to -1 (triggering WARN_ON_ONCE in
>    blk_clear_pm_only()), blocking non-PM requests in blk_queue_enter()
>    and __bio_queue_enter() while the device is RPM_ACTIVE, and the next
>    runtime suspend increments q->pm_only from -1 to 0, letting non-PM
>    requests dispatch while RPM_SUSPENDED. This hits the UFS device
>    well-known LUN by default and SCSI disks with
>    manage_runtime_start_stop enabled (ATA and FireWire sbp2 defaults).
>
> Transition q->rpm_status to RPM_RESUMING in blk_pre_runtime_resume()
> only when it is RPM_SUSPENDED, and call blk_clear_pm_only() in
> blk_post_runtime_resume() only when old_status is RPM_RESUMING, pairing
> each clear with a completed runtime suspend.
>
> Tested on QEMU ARM64 UFS in SDB and MCQ modes by injecting
> runtime-resume START STOP UNIT failures on the UFS device well-known
> LUN, confirming zero pm_only underflows and balanced runtime PM cycles.
>
> Fixes: eef1d74bf88f ("PM: runtime: Only set runtime_error on suspend callback failures")
> Cc: stable@vger.kernel.org # v7.3+
> Reviewed-by: Bart Van Assche <bvanassche@acm.org>
> Signed-off-by: Stanley Jhu <stanleyjhu@google.com>

LGTM

Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>

> ---
> Differences from v1:
> - Move SUSPENDED -> RESUMING explicitly in blk_pre_runtime_resume() and
>   clear pm_only only for RPM_RESUMING in blk_post_runtime_resume()
> - Describe the QEMU UFS test coverage in the commit message
> - Link to v1: https://lore.kernel.org/r/20261029040001.2100001-1-stanleyjhu@google.com
>
>  block/blk-pm.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-pm.c b/block/blk-pm.c
> index 8d3e052f91da..34cc7c5ca04e 100644
> --- a/block/blk-pm.c
> +++ b/block/blk-pm.c
> @@ -142,7 +142,8 @@ EXPORT_SYMBOL(blk_post_runtime_suspend);
>   *
>   * Description:
>   *    Update the queue's runtime status to RESUMING in preparation for the
> - *    runtime resume of the device.
> + *    runtime resume of the device if the queue is runtime suspended, or keep
> + *    RPM_ACTIVE if a previous failed runtime resume already reactivated it.
>   *
>   *    This function should be called near the start of the device's
>   *    runtime_resume callback.
> @@ -153,7 +154,9 @@ void blk_pre_runtime_resume(struct request_queue *q)
>                 return;
>
>         spin_lock_irq(&q->queue_lock);
> -       q->rpm_status = RPM_RESUMING;
> +       /* Keep RPM_ACTIVE if a prior failed resume reactivated the queue. */
> +       if (q->rpm_status == RPM_SUSPENDED)
> +               q->rpm_status = RPM_RESUMING;
>         spin_unlock_irq(&q->queue_lock);
>  }
>  EXPORT_SYMBOL(blk_pre_runtime_resume);
> @@ -168,8 +171,8 @@ EXPORT_SYMBOL(blk_pre_runtime_resume);
>   *    driver or error handler will need to communicate with the device.
>   *
>   *    This function should be called near the end of the device's
> - *    runtime_resume callback to correct queue runtime PM status and re-enable
> - *    peeking requests from the queue.
> + *    runtime_resume callback to mark the queue runtime active and clear
> + *    pm_only if the queue was resuming.
>   */
>  void blk_post_runtime_resume(struct request_queue *q)
>  {
> @@ -185,7 +188,7 @@ void blk_post_runtime_resume(struct request_queue *q)
>         pm_request_autosuspend(q->dev);
>         spin_unlock_irq(&q->queue_lock);
>
> -       if (old_status != RPM_ACTIVE)
> +       if (old_status == RPM_RESUMING)
>                 blk_clear_pm_only(q);
>  }
>  EXPORT_SYMBOL(blk_post_runtime_resume);
> --
> 2.56.0.385.gac671c819a-goog
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active
  2026-11-04 11:27 [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active Stanley Jhu
  2026-11-04 14:34 ` Rafael J. Wysocki (Intel)
@ 2026-11-04 18:34 ` Bart Van Assche
  2026-11-08 10:11 ` shinichiro.kawasaki
  2 siblings, 0 replies; 7+ messages in thread
From: Bart Van Assche @ 2026-11-04 18:34 UTC (permalink / raw)
  To: Stanley Jhu, Jens Axboe
  Cc: Brian Norris, Rafael J . Wysocki, Praveen Talari, Alan Stern,
	linux-block, linux-pm, linux-scsi, linux-kernel, stable

On 11/4/26 3:27 AM, Stanley Jhu wrote:
> Differences from v1:
> - Move SUSPENDED -> RESUMING explicitly in blk_pre_runtime_resume() and
>    clear pm_only only for RPM_RESUMING in blk_post_runtime_resume()

Hi Stanley,

Thank you for having addressed my concerns. There is an existing
issues that you may want to address with a future patch: Queue ACTIVE,
device suspended: after a failed resume, the queue is ACTIVE with
pm_only == 0 while the device is still RPM_SUSPENDED. So
blk_pm_resume_queue() never asks for a resume, and normal I/O goes to
a device the PM core thinks is suspended. A retry only happens if
something else calls pm_runtime_get*(). Commit 6e1fcab00a23 introduced
this behavior on purpose.

Thanks,

Bart.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active
  2026-11-04 11:27 [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active Stanley Jhu
  2026-11-04 14:34 ` Rafael J. Wysocki (Intel)
  2026-11-04 18:34 ` Bart Van Assche
@ 2026-11-08 10:11 ` shinichiro.kawasaki
  2026-11-08 11:59   ` Shin'ichiro Kawasaki
  2 siblings, 1 reply; 7+ messages in thread
From: shinichiro.kawasaki @ 2026-11-08 10:11 UTC (permalink / raw)
  To: linux-block; +Cc: blktests-ci-bot

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

Dear patch submitter,

Blktests CI has tested the following submission:
Status:     FAILURE
Name:       [v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active
Patchwork:  https://patchwork.kernel.org/series/1201669/&state=*
Run record: https://github.com/linux-blktests/linux-block/actions/runs/42332857390


All test cases passed



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active
  2026-11-08 10:11 ` shinichiro.kawasaki
@ 2026-11-08 11:59   ` Shin'ichiro Kawasaki
  2026-11-09 21:40     ` Jens Axboe
  0 siblings, 1 reply; 7+ messages in thread
From: Shin'ichiro Kawasaki @ 2026-11-08 11:59 UTC (permalink / raw)
  To: linux-block; +Cc: blktests-ci-bot

Please ignore this report. It was sent unexpectedly by blktestes-ci
misconfiguration. Sorry for the noise.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active
  2026-11-08 11:59   ` Shin'ichiro Kawasaki
@ 2026-11-09 21:40     ` Jens Axboe
  2026-11-10  1:00       ` Shin'ichiro Kawasaki
  0 siblings, 1 reply; 7+ messages in thread
From: Jens Axboe @ 2026-11-09 21:40 UTC (permalink / raw)
  To: Shin'ichiro Kawasaki, linux-block; +Cc: blktests-ci-bot

On 11/8/26 4:59 AM, Shin'ichiro Kawasaki wrote:
> Please ignore this report. It was sent unexpectedly by blktestes-ci
> misconfiguration. Sorry for the noise.

I would say this happens fairly regularly, but it's actually
more than that these days. Can we improve on this? It's a
lot of extra noise.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active
  2026-11-09 21:40     ` Jens Axboe
@ 2026-11-10  1:00       ` Shin'ichiro Kawasaki
  0 siblings, 0 replies; 7+ messages in thread
From: Shin'ichiro Kawasaki @ 2026-11-10  1:00 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-block, blktests-ci-bot

On Nov 09, 2026 / 14:40, Jens Axboe wrote:
> On 11/8/26 4:59 AM, Shin'ichiro Kawasaki wrote:
> > Please ignore this report. It was sent unexpectedly by blktestes-ci
> > misconfiguration. Sorry for the noise.
> 
> I would say this happens fairly regularly, but it's actually
> more than that these days. Can we improve on this? It's a
> lot of extra noise.

Sorry again for the noise. The blktests-ci system has been testing patches
posted to linux-block for the past few months. I enabled automated e-mail
reports to linux-block about a month ago because I did not see any false
positive reports by then. However, false positives have now been sent out. I
will disable the automated reports and keep monitoring for several more months
to confirm that no false positive are generated before enabling them again.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-11-10  1:00 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-04 11:27 [PATCH v2] block: Keep RPM_ACTIVE in blk_pre_runtime_resume() when already active Stanley Jhu
2026-11-04 14:34 ` Rafael J. Wysocki (Intel)
2026-11-04 18:34 ` Bart Van Assche
2026-11-08 10:11 ` shinichiro.kawasaki
2026-11-08 11:59   ` Shin'ichiro Kawasaki
2026-11-09 21:40     ` Jens Axboe
2026-11-10  1:00       ` Shin'ichiro Kawasaki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox