linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Scott <nathans@sgi.com>
To: Linus Torvalds <torvalds@osdl.org>, Neil Brown <neilb@cse.unsw.edu.au>
Cc: pinotj@club-internet.fr, manfred@colorfullife.com, akpm@osdl.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Oops]  i386 mm/slab.c (cache_flusharray)
Date: Fri, 5 Dec 2003 14:00:19 +1100	[thread overview]
Message-ID: <20031205030018.GA1693@frodo> (raw)
In-Reply-To: <Pine.LNX.4.58.0312041050050.6638@home.osdl.org>

On Thu, Dec 04, 2003 at 11:09:29AM -0800, Linus Torvalds wrote:
> ...
> So the oops it found was apparently triggered by the debugging changes,
> not necessarily by a real bug.
> 
> Ugh, that XFS code is _broken_. Instead of keeping track of how it got the
> memory, it totally forgets where the memory came from, and then it later
> asks "oh, btw, how the hell did I allocate this?".
> 

This patch removes that code, fixes a small memory leak that was
lurking in there too, and adds the missing-bio_put-on-error case
that Neil found in pagebuf.

Neil, with this & Linus' 2 patches (and CONFIG_SLAB_DEBUG off ;)
I now have what looks like a 100% reproducible test case for the
handle_stripe already-freed-bio panic.  This doesn't tickle the
raid5.c BUG_ON you sent me but its exactly the same spot as last
time (i.e. handle_stripe+0xda6), every time.

# raidstart /dev/md0
# mkfs.xfs -f /dev/md0
# mount /dev/md0
# umount /dev/md0
# mount /dev/md0

On my (quad p3) test machine, this second mount panics every time.

cheers.

-- 
Nathan


--- fs/xfs/pagebuf/page_buf.h.orig	2003-12-05 13:47:12.275589232 +1100
+++ fs/xfs/pagebuf/page_buf.h	2003-12-05 13:43:30.898243704 +1100
@@ -123,12 +123,13 @@
 	_PBF_PRIVATE_BH = (1 << 17), /* do not use public buffer heads	   */
 	_PBF_ALL_PAGES_MAPPED = (1 << 18), /* all pages in range mapped	   */
 	_PBF_ADDR_ALLOCATED = (1 << 19), /* pb_addr space was allocated	   */
-	_PBF_MEM_ALLOCATED = (1 << 20), /* pb_mem+underlying pages alloc'd */
+	_PBF_MEM_ALLOCATED = (1 << 20), /* underlying pages are allocated  */
+	_PBF_MEM_SLAB = (1 << 21), /* underlying pages are slab allocated  */
 
-	PBF_FORCEIO = (1 << 21),
-	PBF_FLUSH = (1 << 22),	/* flush disk write cache		   */
-	PBF_READ_AHEAD = (1 << 23),
-	PBF_RUN_QUEUES = (1 << 24), /* run block device task queue	   */
+	PBF_FORCEIO = (1 << 22),
+	PBF_FLUSH = (1 << 23),	/* flush disk write cache		   */
+	PBF_READ_AHEAD = (1 << 24),
+	PBF_RUN_QUEUES = (1 << 25), /* run block device task queue	   */
 
 } page_buf_flags_t;
 
--- fs/xfs/pagebuf/page_buf.c.orig	2003-12-05 13:47:06.888408208 +1100
+++ fs/xfs/pagebuf/page_buf.c	2003-12-05 13:43:30.888245224 +1100
@@ -343,9 +343,6 @@
 			page_cache_release(page);
 		}
 	}
-
-	if (pb->pb_pages != pb->pb_page_array)
-		kfree(pb->pb_pages);
 }
 
 /*
@@ -384,20 +381,17 @@
 		if (pb->pb_flags & _PBF_MEM_ALLOCATED) {
 			if (pb->pb_pages) {
 				/* release the pages in the address list */
-				if (pb->pb_pages[0] &&
-				    PageSlab(pb->pb_pages[0])) {
-					/*
-					 * This came from the slab
-					 * allocator free it as such
-					 */
+				if ((pb->pb_pages[0]) &&
+				    (pb->pb_flags & _PBF_MEM_SLAB)) {
 					kfree(pb->pb_addr);
 				} else {
 					_pagebuf_freepages(pb);
 				}
-
+				if (pb->pb_pages != pb->pb_page_array)
+					kfree(pb->pb_pages);
 				pb->pb_pages = NULL;
 			}
-			pb->pb_flags &= ~_PBF_MEM_ALLOCATED;
+			pb->pb_flags &= ~(_PBF_MEM_ALLOCATED | _PBF_MEM_SLAB);
 		}
 	}
 
@@ -944,7 +938,7 @@
 		return NULL;
 	}
 	/* otherwise pagebuf_free just ignores it */
-	pb->pb_flags |= _PBF_MEM_ALLOCATED;
+	pb->pb_flags |= (_PBF_MEM_ALLOCATED | _PBF_MEM_SLAB);
 	PB_CLEAR_OWNER(pb);
 	up(&pb->pb_sema);	/* Return unlocked pagebuf */
 
@@ -1412,6 +1406,7 @@
 		if (size)
 			goto next_chunk;
 	} else {
+		bio_put(bio);
 		pagebuf_ioerror(pb, EIO);
 	}
 

  parent reply	other threads:[~2003-12-05  3:06 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 [this message]
2003-12-05  6:40       ` Linus Torvalds
2003-12-04 19:19   ` Manfred Spraul
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=20031205030018.GA1693@frodo \
    --to=nathans@sgi.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=neilb@cse.unsw.edu.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).