On Tue, Jan 23, 2018 at 08:37:26AM -0800, Bart Van Assche wrote:

On 01/23/18 08:26, Ming Lei wrote:

quoted

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

Could you explain where to call call_rcu()?  call_rcu() can't be used in
IO path at all.

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.

-- 
Ming