On Mon, Dec 11, 2017 at 01:06:55PM -0800, Linus Torvalds wrote: > On Sun, Dec 10, 2017 at 7:50 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS can result > > in a large number of false positives because lockdep doesn't > > understand how to deal with multiple stacked loop or MD devices. > > Guys, can we just remove this nasty crud already? > > It's not working. Give it up. It was complex, it was buggy, it was slow. > > Now it's causing people to disable lockdep entirely, or play these > kinds of games in unrelated trees. > > It's time to give up on bad debugging, and definitely _not_ enable it > by default for PROVE_LOCKING. To be fair to Byungchul, I think it *can* be valid for finding some classes of bugs. It's just a disaster for anything to do with storage. I crafted this patch as something something which I thought *could* be a path forward; it disables it by default, and gives a warning about how it could cause a lot of pain for storage developers, but if other kernel devs want to use it to potentially find problem in their networking or wifi drivers --- sure, why not? Just make it be something *optional*. If people really want to make this work for storage, what I think we would need is variants of spin_lock_init(), mutex_init(), etc., which take a struct super or a struct block device, with proper documentation so that people don't have to struggle with undocumented C preprocessor macros where every single time I need to mess with lockdep annotations, I have to try figure out exactly what is a class and subclass. So in fact, what I was really hoping for was that some variant of this patch would end up in the sched tree, and get pushed to you v4.15-rcX patch as a regression fix, and I'd drop it from the ext4 tree. - Ted
