On Mon, Sep 27, 2021 at 02:04:41PM +0200, Christoph Hellwig wrote:
> On Thu, Sep 23, 2021 at 02:39:59PM +0800, Ming Lei wrote:
> > > > After blk_mq_unfreeze_queue() returns, blk_try_enter_queue() will return
> > > > true, so new FS I/O from opened bdev still won't be blocked, right?
> > >
> > > It won't be blocked by blk_mq_unfreeze_queue, but because the capacity
> > > is set to 0 it still won't make it to the driver.
> >
> > One bio could be made & checked before set_capacity(0), then is
> > submitted after blk_mq_unfreeze_queue() returns.
> >
> > blk_mq_freeze_queue_wait() doesn't always imply RCU grace period, for
> > example, the .q_usage_counter may have been in atomic mode before
> > calling blk_queue_start_drain() & blk_mq_freeze_queue_wait().
>
> True, but this isn't really a new issue as we never had proper quiesce
> behavior. I have a bunch of ideas of how to make this actually solid,
> but none of them looks like 5.15 material.
It is new issue since edb0872f44ec ("block: move the bdi from the
request_queue to the gendisk").
Previously bdi has longer lifetime than request queue, but now it becomes
not, then either queue_to_disk() or queue->disk may cause panic.
Thanks,
Ming
