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");