Thread (1 message) 1 message, 1 author, 2017-07-05

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

From: Steven Rostedt <hidden>
Date: 2017-07-05 14:56:51

On Wed, 05 Jul 2017 07:50:28 -0700
James Bottomley [off-list ref] wrote:
On Wed, 2017-07-05 at 10:36 -0400, Steven Rostedt wrote:
quoted
On Wed, 5 Jul 2017 15:33:41 +0100
Mark Brown [off-list ref] wrote:
  
quoted
On Wed, Jul 05, 2017 at 04:06:07PM +0200, Greg KH wrote:
  
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help