summaryrefslogtreecommitdiffstats
path: root/mm/slab.c
diff options
context:
space:
mode:
authorJoe Korty <joe.korty@ccur.com>2008-03-05 15:04:59 -0800
committerChristoph Lameter <clameter@sgi.com>2008-03-06 16:21:50 -0800
commit6d2144d355d2a532e5cc3fc12a6ba2a8d4ef15e4 (patch)
tree1c27eecfce86a166ca827bfbd2fe7a46888a7bc0 /mm/slab.c
parentb6210386787728b84db25adc4f1eba70440a4c73 (diff)
downloadop-kernel-dev-6d2144d355d2a532e5cc3fc12a6ba2a8d4ef15e4.zip
op-kernel-dev-6d2144d355d2a532e5cc3fc12a6ba2a8d4ef15e4.tar.gz
slab: NUMA slab allocator migration bugfix
NUMA slab allocator cpu migration bugfix The NUMA slab allocator (specifically, cache_alloc_refill) is not refreshing its local copies of what cpu and what numa node it is on, when it drops and reacquires the irq block that it inherited from its caller. As a result those values become invalid if an attempt to migrate the process to another numa node occured while the irq block had been dropped. The solution is to make cache_alloc_refill reload these variables whenever it drops and reacquires the irq block. The error is very difficult to hit. When it does occur, one gets the following oops + stack traceback bits in check_spinlock_acquired: kernel BUG at mm/slab.c:2417 cache_alloc_refill+0xe6 kmem_cache_alloc+0xd0 ... This patch was developed against 2.6.23, ported to and compiled-tested only against 2.6.25-rc4. Signed-off-by: Joe Korty <joe.korty@ccur.com> Signed-off-by: Christoph Lameter <clameter@sgi.com>
Diffstat (limited to 'mm/slab.c')
-rw-r--r--mm/slab.c5
1 files changed, 2 insertions, 3 deletions
diff --git a/mm/slab.c b/mm/slab.c
index f7faff7..e6c698f 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2964,11 +2964,10 @@ static void *cache_alloc_refill(struct kmem_cache *cachep, gfp_t flags)
struct array_cache *ac;
int node;
- node = numa_node_id();
-
+retry:
check_irq_off();
+ node = numa_node_id();
ac = cpu_cache_get(cachep);
-retry:
batchcount = ac->batchcount;
if (!ac->touched && batchcount > BATCHREFILL_LIMIT) {
/*
OpenPOWER on IntegriCloud