Re: [PATCH 1/5] blk-mq: introduce BLK_STS_DEV_RESOURCE
From: Bart Van Assche <hidden>
Date: 2018-01-23 16:37:26
Also in:
dm-devel, linux-scsi
From: Bart Van Assche <hidden>
Date: 2018-01-23 16:37:26
Also in:
dm-devel, linux-scsi
On 01/23/18 08:26, Ming Lei wrote:
On Tue, Jan 23, 2018 at 08:17:02AM -0800, Bart Van Assche wrote:quoted
On 01/22/18 16:57, Ming Lei wrote:quoted
Even though RCU lock is held during dispatch, preemption or interrupt can happen too, so it is simply wrong to depend on the timing to make sure __blk_mq_run_hw_queue() can see the request in this situation.It is very unlikely that this race will ever be hit because that race exists for less than one microsecond and the smallest timeout that can be specified for delayed queue rerunning is one millisecond. Let's address this race if anyone ever finds a way to hit it.Please don't depend on the timing which is often fragile, as we can make it correct in a generic approach. Also we should avoid to make every driver to follow this way for dealing with most of STS_RESOURCE, right?
Wouldn't it be better to fix that race without changing the block layer API, e.g. by using call_rcu() for delayed queue runs? As you know call_rcu() will only call the specified function after a grace period. Since pushing back requests onto the dispatch list happens with the RCU lock held using call_rcu() for delayed queue runs would be sufficient to address this race. Bart.