Messages in this thread | | | Date | Wed, 9 May 2012 09:05:54 -0500 (CDT) | From | Christoph Lameter <> | Subject | Re: lockdep reports about recursive locking in kmemleak |
| |
On Wed, 9 May 2012, Pekka Enberg wrote:
> > 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" secondary slabs otherwise we would have a bad case of recursion.
If you mark the locks of caches with off-slab features differently from the simple ones then we should be fine.
| |