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

[Bart Van Assche]

On 11/26/25 1:30 PM, Rafael J. Wysocki wrote:
> 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?

The existing code works reliably on a very large number of devices.
Maybe there is a misunderstanding? RQF_PM / BLK_MQ_REQ_PM are set for
requests that should be processed even if the power status is changing
(RPM_SUSPENDING or RPM_RESUMING). The meaning of the 'pm' variable is
as follows: process this request even if a power state change is
ongoing.
> Are you suggesting that q->rpm_status should still be checked before
> calling pm_runtime_resume() or do you mean something else?
The purpose of the code changes from a previous email is not entirely
clear to me so I'm not sure what the code should look like. But to
answer your question, calling blk_pm_resume_queue() if the runtime
status is RPM_SUSPENDED should be safe.
> > 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.
 Hmm ... we may disagree about this. Does what I wrote above make clear
why blk_pm_resume_queue() is called if pm == false?

Thanks,

Bart.