-
Notifications
You must be signed in to change notification settings - Fork 0
block/blk-rq-qos: fix incorrect lock order for rq_qos_mutex and freeze queue #375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: linus-master_base
Are you sure you want to change the base?
Conversation
|
Upstream branch: f824272 |
00d5e5c to
d782508
Compare
|
Upstream branch: f824272 |
0bd2056 to
09bef37
Compare
|
Upstream branch: f824272 |
09bef37 to
9268184
Compare
d782508 to
6099a4d
Compare
|
Upstream branch: e7c375b |
9268184 to
2eb72fc
Compare
6099a4d to
5121c4d
Compare
|
Upstream branch: e7c375b |
2eb72fc to
638cab2
Compare
5121c4d to
4458758
Compare
|
Upstream branch: 8b69055 |
638cab2 to
fa82c41
Compare
4458758 to
6f43942
Compare
|
Upstream branch: fd95357 |
fa82c41 to
3878dec
Compare
6f43942 to
ec9caac
Compare
queue should not be freezed under rq_qos_mutex, see example index commit 9730763 ("block: correct locking order for protecting blk-wbt parameters"), which means current implementation of rq_qos_add() is problematic. Add a new helper and prepare to fix this problem in following patches. Signed-off-by: Yu Kuai <yukuai@fnnas.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
wbt_init() can be called from sysfs attribute and wbt_enable_default(), however the lock order are inversely. - queue_wb_lat_store() freeze queue first, and then wbt_init() hold rq_qos_mutex. In this case queue will be freezed again inside rq_qos_add(), however, in this case freeze queue recursivly is inoperative; - wbt_enable_default() from elevator switch will hold rq_qos_mutex first, and then rq_qos_add() will freeze queue; Fix this problem by converting to use new helper rq_qos_add_freezed() in wbt_init(), and for wbt_enable_default(), freeze queue before calling wbt_init(). Fixes: a13bd91 ("block/rq_qos: protect rq_qos apis with a new lock") Signed-off-by: Yu Kuai <yukuai@fnnas.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
Like wbt, rq_qos_add() can be called from two path and the lock order are inversely: - From ioc_qos_write(), queue is already freezed before rq_qos_add(); - From ioc_cost_model_write(), rq_qos_add() is called directly; Fix this problem by converting to use blkg_conf_open_bdev_frozen() from ioc_cost_model_write(), then since all rq_qos_add() callers already freeze queue, convert to use rq_qos_add_freezed. Signed-off-by: Yu Kuai <yukuai@fnnas.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
…ueue Currently blk-iolatency will hold rq_qos_mutex first and then call rq_qos_add() to freeze queue. Fix this problem by converting to use blkg_conf_open_bdev_frozen() from iolatency_set_limit(), and convert to use rq_qos_add_freezed(). Signed-off-by: Yu Kuai <yukuai@fnnas.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
Now that there is no caller of rq_qos_add(), remove it, and also rename rq_qos_add_freezed() back to rq_qos_add(). Signed-off-by: Yu Kuai <yukuai@fnnas.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
|
Upstream branch: c2f2b01 |
3878dec to
ee130ff
Compare
Pull request for series with
subject: block/blk-rq-qos: fix incorrect lock order for rq_qos_mutex and freeze queue
version: 1
url: https://patchwork.kernel.org/project/linux-block/list/?series=1023924