> > I'm not sure what the right fix is (cc'ing Christoph for the slab.c> > code). The lockdep warning is not in kmemleak, it just happens that> > cache_flusharray() (holding an l3->list_lock) triggers a new allocation> > via debug_object_activate() and kmemleak also tries to allocate its> > metadata, causing a cache_alloc_refill() call which acquires a> > different l3->list_lock, hence the lockdep warning.>> How do we know it's always a different nodelist ("l3")?

The second l3 is from a cache that makes no use of "off-slab" secondaryslabs otherwise we would have a bad case of recursion.

If you mark the locks of caches with off-slab features differently fromthe simple ones then we should be fine.