diff mbox series

block: peek PM requests during runtime PM

Message ID 4a2754ad-d76d-482f-9337-5364d46cd38d.zhaowuyun.zwy@alibaba-inc.com (mailing list archive)
State New, archived
Headers show
Series block: peek PM requests during runtime PM | expand

Commit Message

赵武云 June 11, 2022, 4:46 a.m. UTC 
From: Zhao Wuyun <zhaowuyun.zwy@alibaba-inc.com>

queue blocked during runtime PM when at the following situation:

process A:
    runtime suspend run and set the PM status to RPM_SUSPENDING
    then run req with RQF_PM with blk_execute_rq(req->q, NULL, req, 1)
    then the req queued to head
    it is not executed when the driver is busy

process B:
    normal device management operation
    run req with no RQF_PM with blk_execute_rq(req->q, NULL, req, 1)
    the the req is queued in front of the RQF_PM req of process A
    __blk_run_queue still not run

because the first req is non RQF_PM req and with RQF_SOFTBARRIER,
so the queue is totally blocked when at RPM_SUSPENDING status.

see the following task calltrace:

process A:
    [<ffffff9d87e86150>] __switch_to+0x10c
    [<ffffff9d88ed8ab0>] __schedule+0x670
    [<ffffff9d88ed8d18>] schedule+0x74
    [<ffffff9d88edc8f4>] schedule_timeout+0x328
    [<ffffff9d88ed9130>] io_schedule_timeout+0x24
    [<ffffff9d88ed9b10>] wait_for_common_io+0x90
    [<ffffff9d88ed9bb4>] wait_for_completion_io_timeout+0x24
    [<ffffff9d8829e1e0>] blk_execute_rq+0x88
    [<ffffff9d8859b3a4>] scsi_execute+0x114
    [<ffffff9d885c4070>] sd_sync_cache+0xfc
    [<ffffff9d885c439c>] sd_suspend_common+0x58
    [<ffffff9d885c4338>] sd_suspend_runtime+0x20
    [<ffffff9d885a73cc>] scsi_runtime_suspend+0x70
    [<ffffff9d885341e8>] __rpm_callback+0xcc
    [<ffffff9d885340e8>] rpm_callback+0x5c
    [<ffffff9d88532134>] rpm_suspend+0x1e8
    [<ffffff9d88533b28>] pm_runtime_work+0x7c
    [<ffffff9d87ed31d4>] process_one_work+0x1bc
    [<ffffff9d87ed3668>] worker_thread+0x214
    [<ffffff9d87ed839c>] kthread+0x11c
    [<ffffff9d87e84fcc>] ret_from_fork+0x10

process B:
    [<ffffff9d87e86150>] __switch_to+0x10c
    [<ffffff9d88ed8ab0>] __schedule+0x670
    [<ffffff9d88ed8d18>] schedule+0x74
    [<ffffff9d88edc8f4>] schedule_timeout+0x328
    [<ffffff9d88ed9130>] io_schedule_timeout+0x24
    [<ffffff9d88ed9b10>] wait_for_common_io+0x90
    [<ffffff9d88ed9bb4>] wait_for_completion_io_timeout+0x24
    [<ffffff9d8829e1e0>] blk_execute_rq+0x88
    [<ffffff9d8859b3a4>] scsi_execute+0x114
    [<ffffff9d8859d854>] scsi_test_unit_ready+0x70
    [<ffffff9d885c2f48>] sd_check_events+0xd4
    [<ffffff9d882abde8>] disk_check_events+0x58
    [<ffffff9d882acc0c>] disk_events_workfn+0x20
    [<ffffff9d87ed31d4>] process_one_work+0x1bc
    [<ffffff9d87ed3668>] worker_thread+0x214
    [<ffffff9d87ed839c>] kthread+0x11c
    [<ffffff9d87e84fcc>] ret_from_fork+0x10

Signed-off-by: Zhao Wuyun <zhaowuyun.zwy@alibaba-inc.com>
---
 block/blk-core.c | 9 +++++++++
 1 file changed, 9 insertions(+)

Comments

Christoph Hellwig June 13, 2022, 5:02 p.m. UTC | #1 
What tree is this against?  Neither elv_next_request nor
blk_pm_allow_request exist in upstream, and haven't for a long time.
diff mbox series

Patch

diff --git a/block/blk-core.c b/block/blk-core.c
index a33775cd97be..8b9272bfdc09 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2856,6 +2856,15 @@  static struct request *elv_next_request(struct request_queue *q)
 			if (blk_pm_allow_request(rq))
 				return rq;
 
+			/*
+			 * let the PM request run,
+			 * or the queue may be blocked by the non-PM request
+			 * with RQF_SOFTBARRIER forever while doing runtime PM.
+			 */
+			if (q->rpm_status == RPM_SUSPENDING
+						|| q->rpm_status == RPM_RESUMING)
+				continue;
+
 			if (rq->rq_flags & RQF_SOFTBARRIER)
 				break;
 		}