Re: [PATCH 1/5] blk-mq: introduce BLK_STS_DEV_RESOURCE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux