On Tue, Jan 23, 2018 at 04:54:02PM +0000, Bart Van Assche wrote: > On Wed, 2018-01-24 at 00:49 +0800, Ming Lei wrote: > > On Tue, Jan 23, 2018 at 04:47:11PM +0000, Bart Van Assche wrote: > > > On Wed, 2018-01-24 at 00:41 +0800, Ming Lei wrote: > > > > Could you explain where to call call_rcu()? call_rcu() can't be used in > > > > IO path at all. > > > > > > Can you explain what makes you think that call_rcu() can't be used in the > > > I/O path? As you know call_rcu() invokes a function asynchronously. From > > > Documentation/RCU/Design/Requirements/Requirements.html: > > > > > > The <tt>call_rcu()</tt> function may be used in a number of > > > situations where neither <tt>synchronize_rcu()</tt> nor > > > <tt>synchronize_rcu_expedited()</tt> would be legal, > > > including within preempt-disable code, <tt>local_bh_disable()</tt> code, > > > interrupt-disable code, and interrupt handlers. > > > > OK, suppose it is true, do you want to change most of STS_RESOURCE in > > all drivers to this way? Why can't we use the generic and simple approach > > in this patch? > > Please reread my proposal. I did not propose to change any block drivers. > What I proposed is to change the blk_mq_delay_run_hw_queue() implementation > such that it uses call_rcu() instead of kblockd_mod_delayed_work_on(). > That's a generic and simple approach. How is that enough to fix the IO hang when driver returns STS_RESOURCE and the queue is idle? If you want to follow previous dm-rq's way of call blk_mq_delay_run_hw_queue() in .queue_rq(), the same trick need to be applied to other drivers too, right? Unfortunately most of STS_RESOURCE don't use this trick, but they need to be handled. The patch of 'blk-mq: introduce BLK_STS_DEV_RESOURCE' can fix all these cases. -- Ming
