On Wed, 2017-07-05 at 11:20 -0400, Steven Rostedt wrote: > On Wed, 05 Jul 2017 08:09:49 -0700 > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > you're protecting was accessed outside the lock, which is the > > > > usual source of concurrency problems. In other words lockdep > > > > is useful but it's not a panacea. > > > > > > Still not an excuse to not have lockdep enabled during tests. > > > > OK, what makes you think lockdep isn't enabled? Since Kconfig is > > so complex, I usually use a distro config ... they have it enabled > > (or at least openSUSE does), so it's enabled for everything I do. > > openSuSE has it enabled? I hope not for its production config, as > lockdep has a huge performance penalty. Then, surely, it's the last thing we want when tracking down race conditgions since it will alter timings dramatically. > I'm thinking you don't have it enabled. What config are you looking > at? The actual config that does the testing of locks is > CONFIG_PROVE_LOCKING, which selects LOCKDEP to be compiled in. This is what it has: jejb@jarvis:~/git/linux-build> grep LOCKDEP /boot/config-4.4.73-18.17-default CONFIG_LOCKDEP_SUPPORT=y James -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html