Messages in this thread | | | Subject | Re: [PATCH] block: revert pushing the final release of request_queue to a workqueue. | From | "yukuai (C)" <> | Date | Fri, 7 Feb 2020 18:26:24 +0800 |
| |
On 2020/2/7 17:30, Ming Lei wrote:
> I guess your test case is more complicated than the above CVE, which > should be triggered in single queue case.
No, the test case is from Syzkaller, you can get it from [1] > Looks this approach isn't correct: > > 1) there are other sleepers in __blk_release_queue(), such blk-mq sysfs > kobject_put(), or cancel_delayed_work_sync(), ... > commit dc9edc44de6c pushing the final release of request_queue to a workqueue because sleepers are not allowed. However, since since commit db6d99523560, sleeper is ok because blk_exit_rl() is removed form blkg_free().
> 2) wrt. loop, the request queue's release handler may not be called yet > after loop_remove() returns, so this patch may not avoid the issue in > your step 3 in which blk_mq_debugfs_register fails when adding new loop > device. So release not by wq just reduces the chance, instead of fixing > it completely. > The reason of the problem is because the final release of request_queue may be called after loop_remove() returns. And I think it will be fixed if we revert commit db6d99523560.
Thanks Yu Kuai > > > . >
| |