Messages in this thread Patch in this message | | | Date | Thu, 04 Dec 2003 20:19:53 +0100 | From | Manfred Spraul <> | Subject | Re: [Oops] i386 mm/slab.c (cache_flusharray) |
| |
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"); | |