From: "yukuai (C)" <yukuai3@huawei.com>
To: Ming Lei <ming.lei@redhat.com>
Cc: <axboe@kernel.dk>, <chaitanya.kulkarni@wdc.com>,
<damien.lemoal@wdc.com>, <bvanassche@acm.org>,
<dhowells@redhat.com>, <asml.silence@gmail.com>,
<ajay.joshi@wdc.com>, <linux-block@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <yi.zhang@huawei.com>,
<zhangxiaoxu5@huawei.com>, <luoshijie1@huawei.com>
Subject: Re: [PATCH] block: revert pushing the final release of request_queue to a workqueue.
Date: Fri, 7 Feb 2020 18:26:24 +0800 [thread overview]
Message-ID: <1f2fb027-1d62-2a52-9956-7847fa1baf96@huawei.com> (raw)
In-Reply-To: <20200207093012.GA5905@ming.t460p>
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
>
>
> .
>
next prev parent reply other threads:[~2020-02-07 10:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 11:10 [PATCH] block: revert pushing the final release of request_queue to a workqueue yu kuai
2020-02-07 4:09 ` Bart Van Assche
2020-02-07 6:02 ` yukuai (C)
2020-02-07 7:10 ` yukuai (C)
2020-02-07 9:30 ` Ming Lei
2020-02-07 10:26 ` yukuai (C) [this message]
2020-02-07 12:24 ` yukuai (C)
2020-02-07 13:04 ` Ming Lei
2020-02-08 6:12 ` yukuai (C)
2020-02-10 1:00 ` Bart Van Assche
2020-02-10 2:13 ` yukuai (C)
2020-02-10 2:32 ` Ming Lei
2020-02-10 3:14 ` Bart Van Assche
2020-02-10 8:49 ` yukuai (C)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f2fb027-1d62-2a52-9956-7847fa1baf96@huawei.com \
--to=yukuai3@huawei.com \
--cc=ajay.joshi@wdc.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=chaitanya.kulkarni@wdc.com \
--cc=damien.lemoal@wdc.com \
--cc=dhowells@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luoshijie1@huawei.com \
--cc=ming.lei@redhat.com \
--cc=yi.zhang@huawei.com \
--cc=zhangxiaoxu5@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.