On Mon, Apr 25, 2022 at 3:33 AM Peter Zijlstra <pet...@infradead.org> wrote: > > On Sat, Apr 23, 2022 at 10:27:52AM -0700, Dan Williams wrote: > > > ...so I'm going to drop it and just add a comment about the > > expectations. As Peter said there's already a multitude of ways to > > cause false positive / negative results with lockdep so this is just > > one more area where one needs to be careful and understand the lock > > context they might be overriding. > > One safe-guard might be to check the class you're overriding is indeed > __no_validate__, and WARN if not. Then the unconditional reset is > conistent. > > Then, if/when, that WARN ever triggers you can revisit all this.
Ok, that does seem to need a dummy definition of lockdep_match_class() in the CONFIG_LOCKDEP=n case, but that seems worth it to me for the sanity check.