On Thu, Dec 23, 2021 at 02:40:50PM +0100, Jan Kara wrote: > Hum, I have nothing against this but I'm somewhat wondering: Lockdep was > originally complaining because it somehow managed to find a write whose > completion was indirectly dependent on disk->open_mutex and > destroy_workqueue() could wait for such write to complete under > disk->open_mutex. Now your patch will fix this lockdep complaint but we > still would wait for the write to complete through blk_mq_freeze_queue() > (just lockdep is not clever enough to detect this). So IHMO if there was a > deadlock before, it will be still there with your changes. Now I'm not 100% > sure the deadlock lockdep was complaining about is real in the first place > because it involved some writes to proc files (taking some locks) and > hibernation mutex and whatnot. But it is true that writing to a backing > file will grab fs freeze protection and that can bring with it all sorts of > interesting dependencies. I don't think the problem was a write completion, but the synchronous nature of the workqueue operations. But I also have to admit the whole lockdep vs workqueue thing keeps confusing me.
