Re: [Oops] i386 mm/slab.c (cache_flusharray)

From: Manfred Spraul
Date: Thu Dec 04 2003 - 14:21:30 EST


Linus Torvalds wrote:

Manfred, any ideas? What's different between 2.6.x and 2.4.x in slab?

But it may also be that the bug is in some slab user - since my slab-
translates-to-page-alloc hack always calls the slab constructor function
on every allocation, and the destructor gets called immediately after the
free, my debug version might hide some usage bugs.


The changes between 2.4 and 2.6 are huge, for both debug and non-debug. Slab with debugging enabled now calls the destructors/constructor on every alloc. If page debugging is enabled, then all objects larger than 128 bytes get their own page and are unmapped after kmem_cache_free(). The bio structure is smaller than 128 bytes - that probably explains why slab didn't catch the oopses that were mentioned in the other thread.
Perhaps something like the attached patch could help to trigger the oops: It increase the size of the bio structures, then they are handled by slab debugging.
If it oopses, then call ptrinfo() from the trap handler - it prints the name of the cache and the caller of the last slab operation. And hexdump the object (after ptrinfo mapped it), it contains a backtrace from the kmem_cache_free call.

--
Manfred
--- 2.6/fs/bio.c 2003-10-25 20:43:54.000000000 +0200
+++ build-2.6/fs/bio.c 2003-12-04 20:13:52.000000000 +0100
@@ -798,7 +798,7 @@

size = bp->nr_vecs * sizeof(struct bio_vec);

- bp->slab = kmem_cache_create(bp->name, size, 0,
+ bp->slab = kmem_cache_create(bp->name, max(128,size), 0,
SLAB_HWCACHE_ALIGN, NULL, NULL);
if (!bp->slab)
panic("biovec: can't init slab cache\n");
@@ -815,7 +815,7 @@

static int __init init_bio(void)
{
- bio_slab = kmem_cache_create("bio", sizeof(struct bio), 0,
+ bio_slab = kmem_cache_create("bio", max(128U,sizeof(struct bio)), 0,
SLAB_HWCACHE_ALIGN, NULL, NULL);
if (!bio_slab)
panic("bio: can't create slab cache\n");