| Message ID | 1588740936-28846-1-git-send-email-cang@codeaurora.org (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 05d18ae1cc8a0308b12f37b4ab94afce3535fac9 |
| Headers | show |
| Series | [v4,1/1] scsi: pm: Balance pm_only counter of request queue during system resume | expand |
On 2020-05-05 21:55, Can Guo wrote: > During system resume, scsi_resume_device() decreases a request queue's > pm_only counter if the scsi device was quiesced before. But after that, > if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is > still held (non-zero). Current scsi resume hook only sets the RPM status > of the scsi device and its request queue to RPM_ACTIVE, but leaves the > pm_only counter unchanged. This may make the request queue's pm_only > counter remain non-zero after resume hook returns, hence those who are > waiting on the mq_freeze_wq would never be woken up. Fix this by calling > blk_post_runtime_resume() if a sdev's RPM status was RPM_SUSPENDED. Reviewed-by: Bart Van Assche <bvanassche@acm.org> Thank you for having root-caused and fixed this! Bart.
On Tue, 5 May 2020 21:55:35 -0700, Can Guo wrote: > During system resume, scsi_resume_device() decreases a request queue's > pm_only counter if the scsi device was quiesced before. But after that, > if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is > still held (non-zero). Current scsi resume hook only sets the RPM status > of the scsi device and its request queue to RPM_ACTIVE, but leaves the > pm_only counter unchanged. This may make the request queue's pm_only > counter remain non-zero after resume hook returns, hence those who are > waiting on the mq_freeze_wq would never be woken up. Fix this by calling > blk_post_runtime_resume() if a sdev's RPM status was RPM_SUSPENDED. > > [...] Applied to 5.7/scsi-queue, thanks! [1/1] scsi: pm: Balance pm_only counter of request queue during system resume https://git.kernel.org/mkp/scsi/c/a3b923842626
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c index 3717eea..5f0ad8b 100644 --- a/drivers/scsi/scsi_pm.c +++ b/drivers/scsi/scsi_pm.c @@ -80,6 +80,10 @@ static int scsi_dev_type_resume(struct device *dev, dev_dbg(dev, "scsi resume: %d\n", err); if (err == 0) { + bool was_runtime_suspended; + + was_runtime_suspended = pm_runtime_suspended(dev); + pm_runtime_disable(dev); err = pm_runtime_set_active(dev); pm_runtime_enable(dev); @@ -93,8 +97,10 @@ static int scsi_dev_type_resume(struct device *dev, */ if (!err && scsi_is_sdev_device(dev)) { struct scsi_device *sdev = to_scsi_device(dev); - - blk_set_runtime_active(sdev->request_queue); + if (was_runtime_suspended) + blk_post_runtime_resume(sdev->request_queue, 0); + else + blk_set_runtime_active(sdev->request_queue); } }
During system resume, scsi_resume_device() decreases a request queue's pm_only counter if the scsi device was quiesced before. But after that, if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is still held (non-zero). Current scsi resume hook only sets the RPM status of the scsi device and its request queue to RPM_ACTIVE, but leaves the pm_only counter unchanged. This may make the request queue's pm_only counter remain non-zero after resume hook returns, hence those who are waiting on the mq_freeze_wq would never be woken up. Fix this by calling blk_post_runtime_resume() if a sdev's RPM status was RPM_SUSPENDED. (struct request_queue)0xFFFFFF815B69E938 pm_only = (counter = 2), rpm_status = 0, dev = 0xFFFFFF815B0511A0, ((struct device)0xFFFFFF815B0511A0)).power is_suspended = FALSE, runtime_status = RPM_ACTIVE, (struct scsi_device)0xffffff815b051000 request_queue = 0xFFFFFF815B69E938, sdev_state = SDEV_RUNNING, quiesced_by = 0x0, B::v.f_/task_0xFFFFFF810C246940 -000|__switch_to(prev = 0xFFFFFF810C246940, next = 0xFFFFFF80A49357C0) -001|context_switch(inline) -001|__schedule(?) -002|schedule() -003|blk_queue_enter(q = 0xFFFFFF815B69E938, flags = 0) -004|generic_make_request(?) -005|submit_bio(bio = 0xFFFFFF80A8195B80) Signed-off-by: Can Guo <cang@codeaurora.org> --- Change since v3: - Instead of relying on pm_only counter, rely on the runtime status of a sdev. (Based on the discussion with Bart) Change since v2: - Rebased on 5.8-scsi-queue Change since v1: - Added more debugging context info drivers/scsi/scsi_pm.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)