From: Roland Dreier <rdreier@cisco.com>
To: Linus Torvalds <torvalds@osdl.org>,
"akpm@osdl.org Linux Kernel Mailing List"
<linux-kernel@vger.kernel.org>
Cc: openib-general@openib.org, Or Gerlitz <ogerlitz@voltaire.com>,
Christoph Lameter <clameter@sgi.com>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: [PATCH] slab: Fix kmem_cache_destroy() on NUMA
Date: Mon, 15 May 2006 11:41:00 -0700 [thread overview]
Message-ID: <adaves7rv0j.fsf_-_@cisco.com> (raw)
In-Reply-To: <1147715356.26686.87.camel@localhost.localdomain> (Alan Cox's message of "Mon, 15 May 2006 18:49:16 +0100")
With CONFIG_NUMA set, kmem_cache_destroy() may fail and say "Can't
free all objects." The problem is caused by sequences such as the
following (suppose we are on a NUMA machine with two nodes, 0 and 1):
* Allocate an object from cache on node 0.
* Free the object on node 1. The object is put into node 1's alien
array_cache for node 0.
* Call kmem_cache_destroy(), which ultimately ends up in __cache_shrink().
* __cache_shrink() does drain_cpu_caches(), which loops through all nodes.
For each node it drains the shared array_cache and then handles the
alien array_cache for the other node.
However this means that node 0's shared array_cache will be drained,
and then node 1 will move the contents of its alien[0] array_cache
into that same shared array_cache. node 0's shared array_cache is
never looked at again, so the objects left there will appear to be in
use when __cache_shrink() calls __node_shrink() for node 0. So
__node_shrink() will return 1 and kmem_cache_destroy() will fail.
This patch fixes this by having drain_cpu_caches() do
drain_alien_cache() on every node before it does drain_array() on the
nodes' shared array_caches.
The problem was originally reported by Or Gerlitz <ogerlitz@voltaire.com>.
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
I get a nervous feeling about touching NUMA slab code, because just
the topic alone makes it sound hairy. But I think my diagnosis and
fix are pretty clear, and this definitely fixes crashes seen when
unloading IB modules. It's a regression from 2.6.16, and x86_64
machines with > 1 NUMA node are quite common, so this probably should
go into 2.6.17.
diff --git a/mm/slab.c b/mm/slab.c
index c32af7e..cb747be 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2192,11 +2192,14 @@ static void drain_cpu_caches(struct kmem
check_irq_on();
for_each_online_node(node) {
l3 = cachep->nodelists[node];
- if (l3) {
+ if (l3 && l3->alien)
+ drain_alien_cache(cachep, l3->alien);
+ }
+
+ for_each_online_node(node) {
+ l3 = cachep->nodelists[node];
+ if (l3)
drain_array(cachep, l3, l3->shared, 1, node);
- if (l3->alien)
- drain_alien_cache(cachep, l3->alien);
- }
}
}
next prev parent reply other threads:[~2006-05-15 18:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-11 23:44 Linux v2.6.17-rc4 Linus Torvalds
2006-05-12 6:39 ` Andrew Morton
2006-05-12 11:39 ` Stefan Schweizer
2006-05-15 5:57 ` Benjamin Herrenschmidt
2006-05-12 10:24 ` Erik Mouw
2006-05-12 10:44 ` Michael Buesch
2006-05-12 11:23 ` Olaf Hering
2006-05-12 20:54 ` Michael Buesch
2006-05-12 11:47 ` Erik Mouw
2006-05-12 20:58 ` Michael Buesch
2006-05-12 12:50 ` Andi Kleen
2006-05-12 13:04 ` Johannes Stezenbach
2006-05-12 17:45 ` Jan Engelhardt
2006-05-12 21:19 ` Alistair John Strachan
2006-05-14 7:57 ` Ayaz Abdulla
2006-05-15 5:27 ` Alistair John Strachan
2006-05-20 19:11 ` Alistair John Strachan
2006-05-15 17:49 ` Alan Cox
2006-05-15 18:41 ` Roland Dreier [this message]
2006-05-15 21:47 ` [PATCH] slab: Fix kmem_cache_destroy() on NUMA Christoph Lameter
2006-05-16 4:22 ` Pekka Enberg
2006-05-16 11:57 ` Or Gerlitz
2006-05-16 17:09 ` Linux v2.6.17-rc4 Jan Engelhardt
2006-05-16 17:25 ` Jan Engelhardt
2006-05-17 7:53 ` Avuton Olrich
2006-05-17 8:33 ` Avuton Olrich
2006-05-17 9:37 ` Con Kolivas
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=adaves7rv0j.fsf_-_@cisco.com \
--to=rdreier@cisco.com \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ogerlitz@voltaire.com \
--cc=openib-general@openib.org \
--cc=penberg@cs.helsinki.fi \
--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 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.