Re: [PATCH] block: Fix bug in runtime-resume handling

Alan Stern
2020-08-29T15:26:38Z

On Sat, Aug 29, 2020 at 09:24:30AM +0200, Martin Kepplinger wrote:
> On 27.08.20 22:29, Alan Stern wrote:
> > Instead, look at sd_resume(). That routine calls __scsi_execute()
> > indirectly through sd_start_stop_device(), and the only reason it does
> > this is because the sdkp->device->manage_start_stop flag is set. You
> > ought to be able to clear this flag in sysfs, by writing to
> > /sys/block/sda/device/scsi_disk/*/manage_start_stop. If you do this
> > before allowing the card reader to go into runtime suspend, does it then
> > resume okay?
>
> manage_start_stop in sysfs is 0 here.

Hmmm. I'm wondering about something you wrote back in June
(https://marc.info/?l=linux-scsi&m=159345778431615&w=2):

blk_queue_enter() always - especially when sd is runtime
suspended and I try to mount as above - sets success to be true
for me, so never continues down to bkl_pm_request_resume(). All
I see is "PM: Removing info for No Bus:sda1".

blk_queue_enter() would always set success to be true because pm
(derived from the BLK_MQ_REQ_PREEMPT flag) is true. But why was the
BLK_MQ_REQ_PREEMPT flag set? In other words, where was
blk_queue_enter() called from?

Can you get a stack trace (i.e., call dump_stack()) at exactly this
point, that is, when pm is true and q->rpm_status is RPM_SUSPENDED? Or
do you already know the answer?

Alan Stern