On Thu, Jun 03, 2021 at 05:44:00PM -0700, Bart Van Assche wrote: > On 5/25/21 1:04 AM, Ming Lei wrote: > > wbt_init() calls wbt_alloc() which adds allocated wbt instance into > > q->rq_qos. This way is very dangerous because q->rq_qos is accessed in > > IO fast path. > > > > So far wbt_init() is called in the two code paths: > > > > 1) blk_register_queue(), when the block device has been exposed to > > usespace, so IO may come when adding wbt into q->rq_qos > > > > 2) sysfs attribute store, in which normal IO is definitely allowed > > > > Move wbt allocation into blk_alloc_queue() for avoiding to add wbt > > instance dynamically to q->rq_qos. And before calling wbt_init(), the > > wbt is disabled, so functionally it works as expected. > > I don't like this change since it is not generic - it only helps the WBT > implementation. OK, actually except for wbt, the only one left is iocost which adds rq_qos via cgroup attribute. > > All rq-qos policies call rq_qos_add() and all these policies take effect > before rq_qos_add() returns. Does the q->rq_qos list perhaps have to be > protected with RCU? Would that be sufficient to fix the crashes reported > in the cover letter? Freezing queue should be easier for providing the protection, and I will try that approach. Thanks, Ming
