Thread (9 messages) 9 messages, 2 authors, 2021-06-04

Re: [PATCH 2/4] block: move wbt allocation into blk_alloc_queue

flat view

From: Ming Lei <hidden>
Date: 2021-06-04 01:22:25

On Thu, Jun 03, 2021 at 05:44:00PM -0700, Bart Van Assche wrote:
On 5/25/21 1:04 AM, Ming Lei wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help