Re: [PATCH] block: revert pushing the final release of request_queue to a workqueue.

["yukuai (C)" <yukuai3@huawei.com>]

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
> 
> 
> .
>