From: Steven Rostedt <rostedt@goodmis.org>
To: John Kacur <jkacur@redhat.com>
Cc: Thomas Schauss <schauss@tum.de>,
Thomas Gleixner <tglx@linutronix.de>,
RT <linux-rt-users@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: 3.2-rc1 and nvidia drivers
Date: Tue, 29 Nov 2011 21:36:53 -0500 [thread overview]
Message-ID: <1322620613.17003.110.camel@frodo> (raw)
In-Reply-To: <alpine.LFD.2.00.1111291528590.5855@localhost6.localdomain6>
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@redhat.com>
> 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
>
> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
> mm/slab.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index b615658..635e16a 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3667,7 +3667,9 @@ static void free_block(struct kmem_cache *cachep, void **objpp, int nr_objects,
> * a different cache, refer to comments before
> * alloc_slabmgmt.
> */
> + spin_unlock(&l3->list_lock);
> slab_destroy(cachep, slabp, true);
> + spin_lock(&l3->list_lock);
> } else {
> list_add(&slabp->list, &l3->slabs_free);
> }
next prev parent reply other threads:[~2011-11-30 2:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 9:10 3.2-rc1 and nvidia drivers Javier Sanz
2011-11-16 9:40 ` Thomas Schauss
2011-11-16 15:06 ` Thomas Gleixner
2011-11-28 10:08 ` Thomas Schauss
2011-11-28 11:31 ` John Kacur
2011-11-29 14:31 ` John Kacur
2011-11-30 2:36 ` Steven Rostedt [this message]
2011-11-30 8:23 ` John Kacur
2011-11-30 11:14 ` Peter Zijlstra
2011-11-30 14:14 ` Steven Rostedt
2011-11-30 14:16 ` Peter Zijlstra
2011-11-30 14:28 ` Steven Rostedt
2011-11-30 14:31 ` Steven Rostedt
2011-11-30 14:34 ` Peter Zijlstra
2011-11-30 15:07 ` Thomas Schauss
2011-11-30 15:20 ` Steven Rostedt
2011-12-02 17:41 ` Thomas Schauss
2011-12-02 19:37 ` Steven Rostedt
2011-11-30 13:34 ` Steven Rostedt
2011-11-30 13:39 ` John Kacur
2011-11-30 13:49 ` Steven Rostedt
2011-11-30 13:53 ` John Kacur
2011-11-30 9:06 ` Thomas Schauss
2011-11-16 9:52 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1322620613.17003.110.camel@frodo \
--to=rostedt@goodmis.org \
--cc=jkacur@redhat.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=schauss@tum.de \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.