From: Manfred Spraul <manfred@colorfullife.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: pinotj@club-internet.fr, nathans@sgi.com, akpm@osdl.org,
linux-kernel@vger.kernel.org
Subject: Re: [Oops] i386 mm/slab.c (cache_flusharray)
Date: Thu, 04 Dec 2003 20:19:53 +0100 [thread overview]
Message-ID: <3FCF88D9.7080002@colorfullife.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0312041035530.6638@home.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
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
[-- Attachment #2: patch-bio --]
[-- Type: text/plain, Size: 690 bytes --]
--- 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");
next prev parent reply other threads:[~2003-12-04 19:20 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-04 18:27 [Oops] i386 mm/slab.c (cache_flusharray) pinotj
2003-12-04 18:49 ` Linus Torvalds
2003-12-04 19:09 ` Linus Torvalds
2003-12-04 21:21 ` Nathan Scott
2003-12-05 7:14 ` Christoph Hellwig
2003-12-05 9:34 ` Nathan Scott
2003-12-05 14:22 ` Christoph Hellwig
2003-12-05 3:00 ` Nathan Scott
2003-12-05 6:40 ` Linus Torvalds
2003-12-04 19:19 ` Manfred Spraul [this message]
2003-12-04 21:26 ` Nathan Scott
-- strict thread matches above, loose matches on Subject: below --
2003-12-09 0:57 pinotj
2003-12-09 2:03 ` Nathan Scott
2003-12-09 7:21 ` Christoph Hellwig
2003-12-09 23:58 ` Nathan Scott
2003-12-12 19:00 ` Christoph Hellwig
2003-12-12 20:07 ` Manfred Spraul
2003-12-03 23:06 pinotj
2003-12-03 23:26 ` Linus Torvalds
2003-11-29 17:41 pinotj
2003-12-02 0:36 ` Linus Torvalds
2003-12-02 1:37 ` Nathan Scott
2003-12-02 6:44 ` Nathan Scott
2003-12-02 18:05 ` Mike Fedyk
2003-12-02 20:05 ` Nathan Scott
2003-11-27 18:42 pinotj
2003-11-27 18:55 ` Manfred Spraul
2003-12-02 1:03 ` Mike Fedyk
2003-11-25 17:30 pinotj
2003-11-25 22:51 ` Linus Torvalds
2003-11-27 18:07 ` Manfred Spraul
2003-11-22 7:47 Re: " pinotj
2003-11-22 10:55 ` Manfred Spraul
2003-11-21 18:12 pinotj
2003-11-21 18:58 ` Manfred Spraul
2003-11-20 1:50 pinotj
2003-11-20 2:09 ` Andrew Morton
2003-11-19 18:19 pinotj
2003-11-20 1:07 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FCF88D9.7080002@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathans@sgi.com \
--cc=pinotj@club-internet.fr \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.