On Mon, Jan 10, 2022 at 02:42:34PM +0100, Jan Kara wrote: > I see. But: > a) We didn't fully establish a real deadlock scenario from the lockdep > report, did we? The lockdep report involved suspend locks, some locks on > accessing files in /proc etc. and it was not clear whether it all reflects > a real deadlock possibility or just a fact that lockdep tracking is rather > coarse-grained at times. Now lockdep report is unpleasant and loop device > locking was ugly anyway so your async change made sense but once lockdep is > silenced we should really establish whether there is real deadlock and more > work is needed or not. > > b) Unless we have a realistic plan of moving *all* blk_mq_freeze_queue() > calls from under open_mutex in loop driver, moving stuff "where possible" > from under open_mutex is IMO just muddying water. Agreed. I also have to say I'm not a fan of proliferating the use of task_work_add.
