On 2021/08/28 12:51, Hillf Danton wrote: > On Fri, 27 Aug 2021 23:10:53 +0900 Tetsuo Handa wrote: >> On 2021/08/27 22:02, Hillf Danton wrote: >>> This is a known issue [1] and the quick fix is destroy workqueue without >>> holding lo_mutex. >>> >>> Please post a link to the drivers/block/loop.c you tested, Tetsuo. >>> >>> [1] https://lore.kernel.org/linux-block/0000000000005b27b805c853007b@xxxxxxxxxx/ >>> >> >> Which link? https://lkml.kernel.org/r/2901b9c2-f798-413e-4073-451259718288@xxxxxxxxxxxxxxxxxxx [2]? >> Too many failures to remember... > > Take another look at [2] and what is reported in this thread (see below), > what is common in both cases is lo->workqueue is destroyed under > disk->open_mutex. > > And down the lock chain in blkdev_get_by_dev() disk->open_mutex will be > taken again... seems it will not be solved without taking open_mutex > into account. We are no longer interested in this series which tries to hold lo->lo_mutex from loop_add(). We are discussing https://lkml.kernel.org/r/b9d7b6b1-236a-438b-bee7-6d65b7b58905@xxxxxxxxxxxxxxxxxxx which no longer tries to hold loop_ctl_mutex or lo->lo_mutex from loop_add().
