From: Jan Niehusmann <jan@gondor.com>
To: linux-kernel@vger.kernel.org, adilger@turbolinux.com
Subject: Re: fs corruption with invalidate_buffers()
Date: Thu, 7 Dec 2000 20:05:58 +0100 [thread overview]
Message-ID: <20001207200558.A976@gondor.com> (raw)
In-Reply-To: <20001206030723.A1136@gondor.com>
In-Reply-To: <20001206030723.A1136@gondor.com>; from jan@gondor.com on Wed, Dec 06, 2000 at 03:07:23AM +0100
On Wed, Dec 06, 2000 at 03:07:23AM +0100, Jan Niehusmann wrote:
> While resizing the filesystem, invalidate_buffers() is called from the
> lvm code. (lvm.c, line 2251, in lvm_do_lv_extend_reduce())
> If I remove this call, the corruption goes away. But this is probably not
> the correct fix, as it can cause problems when reducing the lv size.
Some more details:
I added the following code to put_last_free(bh) in buffer.c:
--- buffer.c.orig Wed Dec 6 17:19:57 2000
+++ buffer.c Thu Dec 7 19:55:39 2000
@@ -500,6 +500,11 @@
struct bh_free_head *head = &free_list[BUFSIZE_INDEX(bh->b_size)];
struct buffer_head **bhp = &head->list;
+ if(bh->b_page && Page_Uptodate(bh->b_page)
+ && bh->b_page->mapping) { // XXX ???
+ BUG();
+ }
+
bh->b_state = 0;
spin_lock(&head->lock);
That is, if I want to put a buffer to the free list, I check if it is
mapped and uptodate. If I understand the memory management correctly, this
is a Bad Thing and should not happen. But guess what? It does, in
invalidate_buffers.
I think invalidate_buffers should check if the buffer belongs to a
mapped page, and if it does, invalidate this mapping.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-07 19:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-06 2:07 fs corruption with invalidate_buffers() Jan Niehusmann
2000-12-07 19:05 ` Jan Niehusmann [this message]
2000-12-07 21:30 ` [PATCH] " Jan Niehusmann
2000-12-07 22:03 ` Udo A. Steinberg
2000-12-07 22:26 ` Alexander Viro
2000-12-07 23:37 ` Jan Niehusmann
2000-12-22 0:03 ` Jan Niehusmann
2000-12-22 0:37 ` Linus Torvalds
2000-12-22 0:48 ` Jan Niehusmann
2000-12-22 1:01 ` Linus Torvalds
2000-12-22 1:49 ` Jan Niehusmann
2000-12-22 1:56 ` Alexander Viro
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=20001207200558.A976@gondor.com \
--to=jan@gondor.com \
--cc=adilger@turbolinux.com \
--cc=linux-kernel@vger.kernel.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.