On 01/23/18 08:26, Ming Lei wrote:
On Tue, Jan 23, 2018 at 08:17:02AM -0800, Bart Van Assche wrote:
On 01/22/18 16:57, Ming Lei wrote:
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.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
