On Tue, Sep 27, 2016 at 05:25:36PM -0700, Bart Van Assche wrote: > On 09/22/16 07:52, Jens Axboe wrote: > > Two patches that add the ability for a driver to flag itself > > as wanting the ->queue_rq() invoked in a manner that allows > > it to block. We'll need that for the nbd conversion, to avoid > > having to add workqueue offload. We can use this in the current > > loop mq path as well. > > Hello Jens, > > How can this work since there is code that calls blk_mq_run_hw_queue() with > a spin lock held? From mq_flush_data_end_io(): > > spin_lock_irqsave(&fq->mq_flush_lock, flags); > if (blk_flush_complete_seq(rq, fq, REQ_FSEQ_DATA, error)) > blk_mq_run_hw_queue(hctx, true); > spin_unlock_irqrestore(&fq->mq_flush_lock, flags); > > Sorry that I hadn't noticed this before. > > Bart. Hey, Bart, In this particular case, we're passing async=true to blk_mq_run_hw_queue(), so we do kblockd_schedule_delayed_work_on(blk_mq_hctx_next_cpu(hctx), &hctx->run_work, 0); So ->queue_rq() is being called from a worker thread, not by the calling thread. Jens' patch 2 makes it so that a driver can request that the behavior is always as if async were true. -- Omar -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
