On Sat, Nov 10, 2018 at 07:26:51PM -0500, Waiman Long wrote: > On 11/10/2018 09:14 AM, Peter Zijlstra wrote: > > On Thu, Nov 08, 2018 at 03:34:17PM -0500, Waiman Long wrote: > >> The current lockdep_set_novalidate_class() implementation is like > >> a hack. It assigns a special class key for that lock and calls > >> lockdep_init_map() twice. > > Ideally it would go away.. it is not thing that should be used. > > Yes, I agree. Right now, lockdep_set_novalidate_class() is used in > > drivers/base/core.c: lockdep_set_novalidate_class(&dev->mutex); > drivers/md/bcache/btree.c: lockdep_set_novalidate_class(&b->lock); > drivers/md/bcache/btree.c: > lockdep_set_novalidate_class(&b->write_lock); > > Do you know the history behind making them novalidate? Only of the driver/base/core.c one; there the locking order depends on the hardware and we never quite found a way to annotate that sanely. I forgot most details though. The other stuff I only 'recently' found out about :-( And ideally would have never made it into the tree, but alas.
