Re: [PATCH 1/2] PM: runtime: Fix I/O hang due to race between resume and runtime disable

From: Rafael J. Wysocki

Date: Wed Nov 26 2025 - 16:30:57 EST


On Wed, Nov 26, 2025 at 10:11 PM Bart Van Assche <bvanassche@xxxxxxx> wrote:
>
> On 11/26/25 12:17 PM, Rafael J. Wysocki wrote:
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -309,6 +309,8 @@ int blk_queue_enter(struct request_queue
> > if (flags & BLK_MQ_REQ_NOWAIT)
> > return -EAGAIN;
> >
> > + /* if necessary, resume .dev (assume success). */
> > + blk_pm_resume_queue(pm, q);
> > /*
> > * read pair of barrier in blk_freeze_queue_start(), we need to
> > * order reading __PERCPU_REF_DEAD flag of .q_usage_counter and
>
> blk_queue_enter() may be called from the suspend path so I don't think
> that the above change will work.

Why would the existing code work then?

Are you suggesting that q->rpm_status should still be checked before
calling pm_runtime_resume() or do you mean something else?

> As an example, the UFS driver submits a
> SCSI START STOP UNIT command from its runtime suspend callback. The call
> chain is as follows:
>
> ufshcd_wl_runtime_suspend()
> __ufshcd_wl_suspend()
> ufshcd_set_dev_pwr_mode()
> ufshcd_execute_start_stop()
> scsi_execute_cmd()
> scsi_alloc_request()
> blk_queue_enter()
> blk_execute_rq()
> blk_mq_free_request()
> blk_queue_exit()

In any case, calling pm_request_resume() from blk_pm_resume_queue() in
the !pm case is a mistake.