Re: sort out the lock order in the loop driver v2

On 2021/08/28 12:51, Hillf Danton wrote:

On Fri, 27 Aug 2021 23:10:53 +0900 Tetsuo Handa wrote:

quoted

On 2021/08/27 22:02, Hillf Danton wrote:

quoted

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@google.com/ (local)

Which link? https://lkml.kernel.org/r/2901b9c2-f798-413e-4073-451259718288@i-love.sakura.ne.jp [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@i-love.sakura.ne.jp
which no longer tries to hold loop_ctl_mutex or lo->lo_mutex from loop_add().