Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2017-07-05 at 10:56 -0400, Steven Rostedt wrote:
> On Wed, 05 Jul 2017 07:50:28 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> 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@kernel.org> 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?

That's about 10x more complex than the releases/acquires/must_hold
annotation, which we have fairly dismal coverage on.

If you remember the hotplug annotations, which were a shining example:
there's a limit of complexity before any annotation system simply
becomes a make work tyranny. 

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

James