On Sun, 2018-01-28 at 07:41 +0800, Ming Lei wrote: > Not mention, the request isn't added to dispatch list yet in .queue_rq(), > strictly speaking, it is not correct to call blk_mq_delay_run_hw_queue() in > .queue_rq(), so the current block layer API can't handle it well enough. I disagree that it is not correct to call blk_mq_delay_run_hw_queue() from inside .queue_rq(). Additionally, I have already explained to you in previous e-mails why it's fine to call that function from inside .queue_rq(): - Nobody has ever observed the race you described because the time after which a queue is rerun by blk_mq_delay_run_hw_queue() is much larger than the time during which that race exists. - It is easy to fix this race inside the block layer, namely by using call_rcu() inside the blk_mq_delay_run_hw_queue() implementation to postpone the queue rerunning until after the request has been added back to the dispatch list. > > - The patch at the start of this thread introduces a regression in the > > SCSI core, namely a queue stall if a request completion occurs concurrently > > with the newly added BLK_MQ_S_SCHED_RESTART test in the blk-mq core. > > This patch only moves the blk_mq_delay_run_hw_queue() from scsi_queue_rq() > to blk-mq, again, please explain it in detail how this patch V3 introduces this > regression on SCSI. Please reread the following message: https://marc.info/?l=dm-devel&m=151672480107560. Thanks, Bart. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
