Messages in this thread Patch in this message | | | Date | Wed, 28 Sep 2005 15:50:55 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: 2.6.14-rc1-git-now still dying in mm/slab - this time line 1849 |
| |
On Wed, 28 Sep 2005, Ravikiran G Thirumalai wrote:
> Just might be relevant here, I found a bug with the recent > x86_64 changes to 2.6.14-rc* which causes the node_to_cpumask[] to go bad for > the boot processor. This happens on both amd and em64t boxes. I guess the > kevent/0 cpus_allowed mask might be changed by the bad node_to_cpumask[] > here?
Andrew, could we add the following patch to the kernel to detect conditions in the future? This code will only be compiled in if slab debugging is enabled.
--- [SLAB] Add additional debugging to detect slabs from the wrong node
This patch adds some stack dumps if the slab logic is processing slab blocks from the wrong node. This is necessary in order to detect situations as encountered by Petr.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6.14-rc2/mm/slab.c =================================================================== --- linux-2.6.14-rc2.orig/mm/slab.c 2005-09-27 13:22:30.000000000 -0700 +++ linux-2.6.14-rc2/mm/slab.c 2005-09-28 15:46:31.000000000 -0700 @@ -2421,6 +2421,7 @@ retry: next = slab_bufctl(slabp)[slabp->free]; #if DEBUG slab_bufctl(slabp)[slabp->free] = BUFCTL_FREE; + WARN_ON(numa_node_id() != slabp->nodeid); #endif slabp->free = next; } @@ -2635,8 +2636,10 @@ static void free_block(kmem_cache_t *cac check_spinlock_acquired_node(cachep, node); check_slabp(cachep, slabp); - #if DEBUG + /* Verify that the slab belongs to the intended node */ + WARN_ON(slabp->nodeid != node); + if (slab_bufctl(slabp)[objnr] != BUFCTL_FREE) { printk(KERN_ERR "slab: double free detected in cache " "'%s', objp %p\n", cachep->name, objp); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |