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

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Wed, Jul 5, 2017 at 5:09 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>> > > 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.

Yeah, I've never found those useful at all. What we're trying to do in
drm code is liberally sprinkle lockdep_assert_held into accessor and
helper functions (there's lots of nontrivial stuff where you need a
little bit of computation around a pure access, so doesn't result in
ugly code). That catches a lot of these, but of course not all.

The problem with static annotations is that often the lock you need to
hold isn't statically known, and annotating the entire callchain is a
no-go as James points out. But maybe we could use such annotations
plus a gcc plugin to auto-insert the right lockdep_assert_held every
time you read/write into a given field?

That's not going to cover locking rules where the locking rules change
during the lifetime of an object, but I think even without that it
would cover a _lot_ of cases. And if your static annotation would be
allowed to chase pointers (well, just any C expression that takes the
struct pointer as parameter would be sweet) you could even annotate
fields where the protecting lock is in some parent struct.

Another thing I'm really looking forward to (but it's somehow not
moving fast) is the cross-release stuff. Too many times I've screamed
at kernel backtraces stuck in wait_event, and lockdep could have
directly told me what's wrong long before a stress test successfully
hit that race.

There's definitely a lot of room to prove more stuff in locking using tools.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch