On Sat, 2017-05-27 at 22:21 +0800, Ming Lei wrote: > There are some issues in current blk_mq_quiesce_queue(): > > - in case of direct issue or BLK_MQ_S_START_ON_RUN, dispatch won't > be prevented after blk_mq_quiesce_queue() is returned. > - in theory, new RCU read-side critical sections may begin while > synchronize_rcu() was waiting, and end after returning from > synchronize_rcu(), then dispatch still may be run after > synchronize_rcu() returns Hello Ming, I disagree with the second part of your statement. blk_mq_quiesce_queue() stops all hardware queues before calling synchronize_*rcu(). blk_mq_sched_dispatch_requests() is called with an RCU lock held and checks whether a hctx has been stopped before calling .queue_rq(). That is sufficient to prevent blk_mq_try_issue_directly() to trigger a .queue_rq() call. Bart.
