On Wed 26-01-22 19:27:17, Tetsuo Handa wrote: > On 2022/01/26 16:18, Ming Lei wrote: > > I remember it was to replace original loop_flush() which uses > > wait_for_completion() for draining all inflight bios, but seems > > the flush isn't needed in lo_release(). > > Even if we can remove blk_mq_freeze_queue()/blk_mq_unfreeze_queue() from > lo_release(), we cannot remove > blk_mq_freeze_queue()/blk_mq_unfreeze_queue() from e.g. > loop_set_status(), right? Correct AFAICT. > Then, lo_release() which is called with disk->open_mutex held can be > still blocked at mutex_lock(&lo->lo_mutex) waiting for e.g. > loop_set_status() to call mutex_unlock(&lo->lo_mutex). That is, > lo_open() from e.g. /sys/power/resume can still wait for I/O completion > with disk->open_mutex held. I don't think this is a real problem. If someone is calling loop_set_status() it means the loop device is open and thus lo_release() cannot be running in parallel, can it? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
