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