Thread (23 messages) 23 messages, 3 authors, 2018-01-24

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

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help