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
.
