Re: [PATCH v8 6/8] block: Schedule runtime resume earlier
From: Bart Van Assche <bvanassche@acm.org>
Date: 2018-09-19 21:39:35
On Wed, 2018-09-19 at 12:05 +0800, Ming Lei wrote:
Looks this patch may introduce the following race between queue freeze and runtime suspend: ------------------------------------------------------------------- ------- CPU0 CPU1 CPU2 ------------------------------------------------------------------- ------- blk_freeze_queue() blk_mq_alloc_request() blk_queue_enter() blk_pm_request_ resume() wait_event() blk_pre_runtime_suspend() ->blk_set_pm_only ... blk_post_runtime_suspend() ... blk_mq_unfreeze_queue() ------------------------------------------------------------------- ------- - CPU0: queue is frozen - CPU1: one new request comes, and see queue is frozen, but queue isn't runtime-suspended yet, then blk_pm_request_resume() does nothing. So this allocation is blocked in wait_event(). - CPU2: runtime suspend comes, and queue becomes runtime-suspended now - CPU0: queue is unfreeze, but the new request allocation in CPU1 may never be done because the queue is runtime suspended, and wait_event() won't return. And the expected result is that the queue becomes active and the allocation on CPU1 is done immediately.
Hello Ming, Just like for the scenario Jianchao reported, I will address this by only allowing the suspend to proceed if q_usage_counter == 0. Bart.