On Mon, Apr 25, 2022 at 9:05 AM Dan Williams <dan.j.willi...@intel.com> wrote: > > 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.
Thankfully the comment in lockdep.h to not define a lockdep_match_class() for the CONFIG_LOCKDEP=n stopped me from going that direction.