All of lore.kernel.org
 help / color / mirror / Atom feed
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");

  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.