From: Arjan van de Ven <arjan@infradead.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@osdl.org>,
sekharan@us.ibm.com, linux-kernel@vger.kernel.org,
nagar@watson.ibm.com, balbir@in.ibm.com
Subject: Re: [patch] lockdep: annotate mm/slab.c
Date: Thu, 13 Jul 2006 21:21:12 +0200 [thread overview]
Message-ID: <1152818472.3024.75.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0607131156060.5623@g5.osdl.org>
On Thu, 2006-07-13 at 11:56 -0700, Linus Torvalds wrote:
>
> On Thu, 13 Jul 2006, Pekka Enberg wrote:
> >
> > What's "nested lock" btw? If I understood from the other patch, you're
> > talking about ac->lock. Surely you can't take the same lock twice but
> > it's perfectly legal to take lock as long as the ac instance is
> > different...
>
> Normally, no. You can't take another lock just because the instance is
> different. That causes ABBA deadlocks unless you have some underlying
> _ordering_ of the different lock instances.
and that is the case here fwiw;
the OFF_SLAB metadata thing is tricky when freeing stuff:
for kfree() you take the lock for your own slab, do some management and
then do effectively do a kfree() on your off-slab metadata. Which then
takes the lock for the kmalloc slab of the size of your metadata.
This is a natural order, you assume (and pray) that this kmalloc slab is
not in itself a slab with off-slab metadata, so that there can't be a BA
of the ABBA deadlock. [*]
This is what needed the lockdep annotation; lockdep by default thinks
all slabs are equal (by virtue of sharing the spin_lock_init()
location). And because of the slab-internal knowledge of off-slab versus
not-off-slab they're not equal.
Now there are two choices for annotation: tell the spin lock aquisition
that there is a natural hierarchy (eg spin_lock_depends) and this is
what Ingo tried at first. Except that it got horribly complex, messy and
just outright gross.
The second option is telling lockdep that kmalloc slabs without off-slab
metadata are really different in terms of locking rules (eg they have a
separate identity than the other slabs); and that is why my patch does
(or at least tries to; it works for my machines but the slab
initialization code is horribly complex wrt hotplug and numa so I may
have missed a corner case initialization).
The downside of this 'separate identity' is that you basically split the
lock history, meaning that the graph of past history is not built up as
fast as it could have been. Slab is used so much that that isn't a big
deal; for other more exotic cases that's more of a quality issue.
Greetings,
Arjan van de Ven
[*] Note Note Note
there is a corner case in the slab code that I personally don't trust at
all. In the NUMA case, if the memory is not originally from your own
node, the cache_free_alien() function takes, while having your own local
lock, the lock of the remote node as well. (at least on my reading of
the code) to free the memory to that node. I have yet to see where in
the code it safeguards against that remote node doing the exact same
thing in the opposite direction concurrently, and causing a basic ABBA
deadlock.
next prev parent reply other threads:[~2006-07-13 19:21 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-13 3:59 Random panics seen in 2.6.18-rc1 Chandra Seetharaman
2006-07-13 7:12 ` Ingo Molnar
2006-07-13 7:28 ` Andrew Morton
2006-07-13 7:26 ` Ingo Molnar
2006-07-13 7:44 ` Andrew Morton
2006-07-13 7:46 ` Ingo Molnar
2006-07-13 8:49 ` Ingo Molnar
2006-07-13 8:42 ` Ingo Molnar
2006-07-13 8:46 ` [patch] lockdep: more annotations for mm/slab.c Ingo Molnar
2006-07-13 9:08 ` Andrew Morton
2006-07-13 9:18 ` Ingo Molnar
2006-07-13 10:44 ` Arjan van de Ven
2006-07-13 10:58 ` Arjan van de Ven
2006-07-13 12:44 ` [patch] lockdep: undo mm/slab.c annotation Ingo Molnar
2006-07-13 12:46 ` [patch] lockdep: annotate mm/slab.c Ingo Molnar
2006-07-13 15:45 ` Pekka Enberg
2006-07-13 19:55 ` Ingo Molnar
2006-07-13 15:58 ` Pekka Enberg
2006-07-13 18:56 ` Linus Torvalds
2006-07-13 19:21 ` Arjan van de Ven [this message]
2006-07-13 22:27 ` Christoph Lameter
2006-07-13 23:08 ` Alok kataria
2006-07-13 22:51 ` Christoph Lameter
2006-07-13 23:16 ` Andrew Morton
2006-07-14 2:29 ` Christoph Lameter
2006-07-14 2:46 ` Christoph Lameter
2006-07-14 3:02 ` Andrew Morton
2006-07-14 3:35 ` Christoph Lameter
2006-07-14 3:45 ` Christoph Lameter
2006-07-14 16:48 ` Alok kataria
2006-07-14 2:54 ` Andrew Morton
2006-07-14 2:59 ` Christoph Lameter
2006-07-13 19:32 ` Ingo Molnar
2006-07-13 18:50 ` Linus Torvalds
2006-07-13 19:06 ` Arjan van de Ven
2006-07-13 19:21 ` Linus Torvalds
2006-07-13 19:26 ` Arjan van de Ven
2006-07-13 19:17 ` Ingo Molnar
2006-07-13 19:19 ` Ingo Molnar
2006-07-13 21:30 ` Andrew Morton
2006-07-13 13:51 ` Random panics seen in 2.6.18-rc1 Chandra Seetharaman
2006-07-13 16:05 ` Chandra Seetharaman
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=1152818472.3024.75.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nagar@watson.ibm.com \
--cc=penberg@cs.helsinki.fi \
--cc=sekharan@us.ibm.com \
--cc=torvalds@osdl.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®