All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Lameter <cl@gentwo.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Sitsofe Wheeler <sitsofe@yahoo.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, penberg@kernel.org,
	mpm@selenic.com, linux-mm@kvack.org,
	David Rientjes <rientjes@google.com>
Subject: Re: lockdep recursive locking detected (rcu_kthread / __cache_free)
Date: Tue, 04 Oct 2011 17:09:50 +0200	[thread overview]
Message-ID: <1317740991.32543.19.camel@twins> (raw)
In-Reply-To: <alpine.DEB.2.00.1110040948230.8522@router.home>

On Tue, 2011-10-04 at 09:50 -0500, Christoph Lameter wrote:
> On Tue, 4 Oct 2011, Peter Zijlstra wrote:
> 
> > It could of course be I got confused and broke stuff instead, could
> > someone who knows slab (I guess that's either Pekka, Christoph or David)
> > stare at those patches?
> 
> Why is the loop in init_lock_keys only running over kmalloc caches and not
> over all slab caches?

A little digging brings us to: 056c62418cc639bf2fe962c6a6ee56054b838bc7
which seems to have introduced that.

>  It seems that this has to be especially applied to
> regular slab caches because those are the ones that mostly have off slab
> structures. So modify init_lock_keys to run over all slab caches?

That sounds about right, worth a try. Also over new caches, the above
reverenced commit removes a hook from kmem_cache_init() which we really
need I suppose.

I'll try and compose a patch if nobody beats me to it, but need to run
an errand first.

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Lameter <cl@gentwo.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Sitsofe Wheeler <sitsofe@yahoo.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, penberg@kernel.org,
	mpm@selenic.com, linux-mm@kvack.org,
	David Rientjes <rientjes@google.com>
Subject: Re: lockdep recursive locking detected (rcu_kthread / __cache_free)
Date: Tue, 04 Oct 2011 17:09:50 +0200	[thread overview]
Message-ID: <1317740991.32543.19.camel@twins> (raw)
In-Reply-To: <alpine.DEB.2.00.1110040948230.8522@router.home>

On Tue, 2011-10-04 at 09:50 -0500, Christoph Lameter wrote:
> On Tue, 4 Oct 2011, Peter Zijlstra wrote:
> 
> > It could of course be I got confused and broke stuff instead, could
> > someone who knows slab (I guess that's either Pekka, Christoph or David)
> > stare at those patches?
> 
> Why is the loop in init_lock_keys only running over kmalloc caches and not
> over all slab caches?

A little digging brings us to: 056c62418cc639bf2fe962c6a6ee56054b838bc7
which seems to have introduced that.

>  It seems that this has to be especially applied to
> regular slab caches because those are the ones that mostly have off slab
> structures. So modify init_lock_keys to run over all slab caches?

That sounds about right, worth a try. Also over new caches, the above
reverenced commit removes a hook from kmem_cache_init() which we really
need I suppose.

I'll try and compose a patch if nobody beats me to it, but need to run
an errand first.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-10-04 15:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 17:53 lockdep recursive locking detected (rcu_kthread / __cache_free) Sitsofe Wheeler
2011-10-03 20:31 ` Paul E. McKenney
2011-10-03 20:31   ` Paul E. McKenney
2011-10-03 20:46   ` Christoph Lameter
2011-10-03 20:46     ` Christoph Lameter
2011-10-03 21:06     ` Peter Zijlstra
2011-10-03 21:06       ` Peter Zijlstra
2011-10-03 21:47     ` Paul E. McKenney
2011-10-03 21:47       ` Paul E. McKenney
2011-10-04 14:28       ` Christoph Lameter
2011-10-04 14:28         ` Christoph Lameter
2011-10-04 14:40         ` Peter Zijlstra
2011-10-04 14:40           ` Peter Zijlstra
2011-10-04 14:50           ` Christoph Lameter
2011-10-04 14:50             ` Christoph Lameter
2011-10-04 15:09             ` Peter Zijlstra [this message]
2011-10-04 15:09               ` Peter Zijlstra

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=1317740991.32543.19.camel@twins \
    --to=peterz@infradead.org \
    --cc=cl@gentwo.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=mpm@selenic.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=sitsofe@yahoo.com \
    /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.