Re: [QUESTION] blk_mq_freeze_queue in elevator_init_mq

[yangerkun <yangerkun@huawei.com>]

On 2021/11/17 12:11, Bart Van Assche wrote:
> On 11/16/21 19:37, yangerkun wrote:
>> This commit add blk_mq_freeze_queue in elevator_init_mq which try to
>> make sure no in-flight request while we go through blk_mq_init_sched.
>> But does there any drivers can leave IO alive while we go through
>> elevator_init_mq？ And if no, maybe we can just remove this logical to
>> fix the regression...
> 
> Does this untested patch help? Please note that I'm not recommending to
> integrate this patch in the upstream kernel but if it helps it can be a
> building block of a solution.
> 
> Thanks,
> 
> Bart.
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 3ab34c4f20da..b85dcb72a579 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -167,6 +167,7 @@ void blk_freeze_queue_start(struct request_queue *q)
>           mutex_unlock(&q->mq_freeze_lock);
>           if (queue_is_mq(q))
>               blk_mq_run_hw_queues(q, false);
> +        synchronize_rcu_expedited();
>       } else {
>           mutex_unlock(&q->mq_freeze_lock);
>       }
> .

Sorry for that it's blk_mq_quiesce_queue which actually introduce the 
RCU gap... I have try synchronize_rcu_expedited in blk_mq_quiesce_queue 
which seems useless...