On Wed, Apr 13, 2022 at 03:01:21PM -0700, Dan Williams wrote:
> > That's not an obvious conclusion; lockdep has lots of funny annotations,
> > subclasses is just one.
> >
> > I think the big new development in lockdep since that time with Alan
> > Stern is that lockdep now has support for dynamic keys; that is lock
> > keys in heap memory (as opposed to static storage).
>
> Ah, I was not aware of that, that should allow for deep cleanups of
> this proposal.
> > If you want lockdep validation for one (or more) dev->mutex instances,
> > why not pull them out of the no_validate class and use the normal
> > locking?
>
> Sounds perfect, just didn't know how to do that with my current
> understanding of how to communicate this to lockdep.
>
> >
> > This is all quite insane.
>
> Yes, certainly in comparison to your suggestion on the next patch.
> That looks much more sane, and even better I think it allows for
> optional lockdep validation without even needing to touch
> include/linux/device.h.
Right, so lockdep has:
- classes, based off of lock_class_key address;
* lock_class_key should be static storage; except now we also have:
lockdep_{,un}register_key()
which allows dynamic memory (aka. heap) to be used for classes,
important to note that lockdep memory usage is still static storage
because the memory allocators use locks too. So if you register too
many dynamic keys, you'll run out of lockdep memory etc.. so be
careful.
* things like mutex_init() have a static lock_class_key per site
and hence every lock initialized by the same code ends up in the
same class by default.
* can be trivially changed at any time, assuming the lock isn't held,
using lockdep_set_class*() family.
(extensively used all over the kernel, for example by the vfs to
give each filesystem type their own locking order rules)
* lockdep_set_no_validate_class() is a magical variant of
lockdep_set_class() that sets a magical lock_class_key.
* can be changed while held using lock_set_class()
( from a lockdep pov it unlocks the held stack,
changes the class of your lock, and re-locks the
held stack, now with a different class nesting ).
Be carefule! It doesn't forget the old nesting order, so you
can trivally generate cycles.
- subclasses, basically distinct addresses inside above mentioned
lock_class_key object, limited to 8. Normally used with
*lock_nested() family of functions. Typically used to lock multiple
instances of a single lock class where there is defined order between
instances (see for instance: double_rq_lock()).
- nest_lock; eg. mutex_lock_nest_lock(), which allows expressing things
like: multiple locks of class A can be taken in any order, provided
we hold lock B.
With many of these, it's possible to get it wrong and annotate real
deadlocks away, so be careful :-)
