On Thu, 2017-05-04 at 01:19 +0800, Ming Lei wrote: > On Wed, May 03, 2017 at 05:08:30PM +0000, Bart Van Assche wrote: > > Callers of blk_mq_quiesce_queue() really need blk_mq_stop_hw_queue() to > > cancel delayed work synchronously. The above call stack shows that we have > > to do something about the blk_mq_stop_hw_queue() calls from inside .queue_rq() > > functions for queues for which BLK_MQ_F_BLOCKING has not been set. I'm not > > sure what the best approach would be: setting BLK_MQ_F_BLOCKING for queues > > that call blk_mq_stop_hw_queue() from inside .queue_rq() or creating two > > versions of blk_mq_stop_hw_queue(). > > I think either synchronize_srcu() or synchronize_rcu() can handle > this, since they are waiting for completion of .queue_rq(). So looks > cancel_delayed_work_sync() shouldn't be needed? Hello Ming, What you wrote is not correct. synchronize_*rcu() only waits for ongoing .queue_rq() calls. cancel_delayed_work() will return immediately if it is called after hctx->run_work has already been started. And the hctx->run_work handler can trigger new .queue_rq() calls after synchronize_*rcu() has already returned. Bart.
