Thread (8 messages) 8 messages, 3 authors, 2021-11-18

Re: [QUESTION] blk_mq_freeze_queue in elevator_init_mq

From: yangerkun <hidden>
Date: 2021-11-17 08:39:46


On 2021/11/17 12:11, Bart Van Assche wrote:
quoted hunk ↗ jump to hunk
On 11/16/21 19:37, yangerkun wrote:
quoted
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...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help