On Sat, Dec 9, 2017 at 6:02 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > 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. > The "silly setup" is not something that any sane admin will do, but there a lot of crazy stuff you can do with loop, like: - create a file in FS1 on VG1/LV1 - setup loop dev - add the loop dev to VG1 - extend LV1 onto loopdev - extend FS1 onto loopdev That setup is possible. That setup can deadlock. I am not trying to defend lockdep developers regressing our tests and "forcing" the burden of annotations on fs developers. That is wrong. The burden of proof should be on lockdep developers and IMO is was premature to force completion lockdep. But for full disclosure, I am stating a fact that lockdep is not meant to tell us that we hit a deadlock. lockdep is meant to tell us that a deadlock is possible with current code. And what do you know - deadlock is possible, just not with your setup. It has always been possible - completion lockdep just exposed that. Going forward, it is clear that with completion lockdep, the static lockdep annotations for fs locks are not sufficient. We need to have a very simple way of annotating a lock that is associated with an fs instance rather than an fs type. Amir.
