On Wed, Nov 30, 2011 at 3:36 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Tue, 2011-11-29 at 15:31 +0100, John Kacur wrote: >> On Mon, 28 Nov 2011, John Kacur wrote: > >> > Hmm, I think I see how this can happen. >> > >> > cache_flusharray() >> > spin_lock(&l3->list_lock); >> > free_block(cachep, ac->entry, batchcount, node); >> > slab_destroy() >> > kmem_cache_free() >> > __cache_free() >> > cache_flusharray() >> > >> >> Could you try the following patch to see if it gets rid of your lockdep >> splat? (plan to neaten it up and send it to lkml if it works for you.) >> >> >From 29bf37fc62098bc87960e78f365083d9f52cf36a Mon Sep 17 00:00:00 2001 >> From: John Kacur <jkacur@xxxxxxxxxx> >> Date: Tue, 29 Nov 2011 15:17:54 +0100 >> Subject: [PATCH] Drop lock in free_block before calling slab_destroy to prevent lockdep splats >> >> This prevents lockdep splats due to this call chain >> cache_flusharray() >> spin_lock(&l3->list_lock); >> free_block(cachep, ac->entry, batchcount, node); >> slab_destroy() >> kmem_cache_free() >> __cache_free() >> cache_flusharray() > > John, > > No, this is a false positive, and the code is correct, lockdep just > needs to be tweaked. If this was a real bug, then it would have locked > up here and not have continued, as spinlocks are not recursive. > > This was complained about in mainline too: > > https://lkml.org/lkml/2011/10/3/364 > > There was a fix to a similar bug that Peter pointed out, but this bug > doesn't look like it was fixed. > > Peter? > Steve - I'm aware that this is a false positive, I discussed this with Peter already. Normally I don't like the idea of changing code for a tool, but if you see the comment that they wrote above where I put the unlock - it was an extraordinary thing NOT to drop the lock here, as slab_destroy is normally called without it. It doesn't seem like good form to me to hold a lock longer than you need it, and it is a simple solution to getting rid of the lockdep splat. (false positive, or false negative, depending on how you see it.) That being said, I'm not adverse to another solution either, but this one should work and is simple. John -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
