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 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. 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
