On Sat, Oct 19, 2024 at 09:37:27PM +0900, Sergey Senozhatsky wrote:
> On (24/10/19 20:32), Ming Lei wrote:
> [..]
> > > > When ->release() waits in blk_enter_queue(), the following code block
> > > >
> > > > mutex_lock(&disk->open_mutex);
> > > > __blk_mark_disk_dead(disk);
> > > > xa_for_each_start(&disk->part_tbl, idx, part, 1)
> > > > drop_partition(part);
> > > > mutex_unlock(&disk->open_mutex);
> > >
> > > blk_enter_queue()->schedule() holds ->open_mutex, so that block
> > > of code sleeps on ->open_mutex. We can't drain under ->open_mutex.
> >
> > We don't start to drain yet, then why does blk_enter_queue() sleeps and
> > it waits for what?
>
> Unfortunately I don't have a device to repro this, but it happens to a
> number of our customers (using different peripheral devices, but, as far
> as I'm concerned, all running 6.6 kernel).
I can understand the issue on v6.6 because it doesn't have commit
7e04da2dc701 ("block: fix deadlock between sd_remove & sd_release").
But for the latest upstream, I don't get idea how it can happen.
Thanks,
Ming
