On Wed, 05 Jul 2017 07:50:28 -0700 James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 2017-07-05 at 10:36 -0400, Steven Rostedt wrote: > > On Wed, 5 Jul 2017 15:33:41 +0100 > > Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Jul 05, 2017 at 04:06:07PM +0200, Greg KH wrote: > > > > > > > > > > > I don't mean to poo-poo the idea, but please realize that around > > > > 75% of the kernel is hardware/arch support, so that means that > > > > 75% of the changes/fixes deal with hardware things (yes, change > > > > is in direct correlation to size of the codebase in the tree, > > > > strange but true). > > > > > > Then add in all the fixes for concurrency/locking issues and so on > > > that're hard to reliably reproduce as well... > > > > All tests should be run with lockdep enabled ;-) Which a surprising > > few developers appear to do :-p > > Lockdep checks the locking hierarchies and makes assumptions about them > which it then validates ... it doesn't tell you if the data you think We should probably look at adding infrastructure that helps in that. RCU already has a lot of there to help know if data is being protected by RCU or not. Hmm, maybe we could add a __rcu like type that we can associate protected data with, where a config can associate access to a variable with a lock being held? > 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. -- Steve -- 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
