On Sat, Dec 09, 2017 at 10:44:33AM +0200, Amir Goldstein wrote: > The honest truth is that loop nested fs can *really* cause a > deadlock with silly setups. completion lockdep is the unlucky > messenger that was trying to bring that to our attention. What is the "silly setup" (I'm not saying kernel bugs, but rather things which a sysadmin might want to set up) that would cause deadlock? In the example you gave, the block allocation is happenig in two different file system instances, so if lockdep whinges, that's another example of a false positive. > Byungchul, > > Seeing how your changes to lockdep completion has caused pain to fs developers, > I recommend that when checking your changes you run Ted's kvm-xfstests to > verify it is not causing any regressions w.r.t. false positive lockdep warnings. > This test VM is specifically designed for other subsystem developers to > easily run the fs subsystem testsuite. How about a Kconfig to disable completion lockdep? It's clearly not ready for prime time. At the *minimum*, block devices and struct supers need to have the ability to have unique id's, and there needs to be a trivial way to mix that into lockdep key that doesn't require every single subsystem and device driver author to use undocumented lockdep interfaces to make the right thing happen. Instead, we need abstractions that make the right thing happen by default. Until this happens, we either need to disable lockdep completions, or disable lockdep altogether. I'd prefer the former --- and I'll even offer to run a Kconfig fixup patch through the ext4 tree to do this, "free of charge" --- but if you NACK such a change, I'll probably end up following Dave Chinner's wise counsel and suggest to all ext4 developers to disable lockdep. - Ted
