[Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking
Steven Rostedt
rostedt at goodmis.org
Wed Jul 5 14:56:51 UTC 2017
On Wed, 05 Jul 2017 07:50:28 -0700
James Bottomley <James.Bottomley at 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 at 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?
> 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
More information about the Ksummit-discuss
mailing list