public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
To: Alexander Viro <viro@math.psu.edu>
Cc: Andrew Morton <andrewm@uow.edu.au>,
	Petr Vandrovec <vandrove@vc.cvut.cz>,
	Linus Torvalds <torvalds@transmeta.com>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Jonathan Hudson <jonathan@daria.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [resync?] Re: corruption
Date: Sun, 3 Dec 2000 17:56:10 -0700	[thread overview]
Message-ID: <20001203175610.A24729@vger.timpanogas.org> (raw)
In-Reply-To: <3A2ABEC5.97AF9C61@uow.edu.au> <Pine.GSO.4.21.0012031730020.3601-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0012031730020.3601-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Sun, Dec 03, 2000 at 05:45:57PM -0500

On Sun, Dec 03, 2000 at 05:45:57PM -0500, Alexander Viro wrote:
> 
> 
> On Mon, 4 Dec 2000, Andrew Morton wrote:
> 
> > Sorry, it's still failing.  It took three hours.
> 
> Yes. For one thing, original was plain wrong wrt locking (lru_list_lock
> should be held). For another, it does not take care of metadata. And
> that's way more serious. What really happens:
> 
> ext2_truncate() got a buffer_head of indirect block that is going to
> die. Fine, we release the blocks refered from it and... do bforget()
> on our block. Notice that we are not guaranteed that bh will actually
> die here. buffer.c code might bump its ->b_count for a while, it might
> be written out right now, etc. As the result, bforget() leaves the
> sucker alive. It's not a big deal, since we will do unmap_underlying_metadata()
> before we write anything there (if it will be reused for data) or we'll
> just pick the bh and zero the buffer out (if it will be reused for metadata).
> 
> Unfortunately, we also leave it on the per-inode dirty blocks list. Guess
> what happens if inode is destroyed, page that used to hold it gets reused
> and bh gets finally written? Exactly.
> 
> Suggested fix: void bforget_inode(struct buffer_head *bh) that would
> be a copy of __bforget(), except that it would call remove_inode_queue(bh)
> unconditionally. And replace bforget() with bforget_inode() in those places
> of ext2/inode.c that are followed by freeing the block.
> 
> Comments? I'll do a patch, but I'ld really like to know what had already
> gone into the main tree. Linus, could you put the 12-pre4-dont-use on
> ftp.kernel.org?

Al,

I am always amazed at how rapidly you seem to be able to run down some
of these file system corruption problems.   You seem to understand the
interaction of this layer extremely well.  :-)

Jeff

> 
> -
> 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/
-
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/

  reply	other threads:[~2000-12-04  0:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-29 21:54 corruption Andries.Brouwer
2000-11-29 22:18 ` corruption Alexander Viro
2000-11-30 14:21   ` corruption Andrew Morton
2000-11-30 18:39     ` corruption Jonathan Hudson
2000-11-30 19:07       ` corruption Alexander Viro
2000-11-30 21:35         ` corruption Andrew Morton
2000-12-01  0:57           ` corruption Andrew Morton
2000-12-01 12:18             ` corruption Jens Axboe
2000-12-01 12:34               ` corruption Andrew Morton
2000-12-01 12:37                 ` corruption Jens Axboe
2000-12-01 12:23             ` corruption Andrew Morton
2000-12-01 15:04               ` corruption Lawrence Walton
2000-12-01 14:16           ` corruption Stephen C. Tweedie
2000-12-01 23:28             ` corruption Andrew Morton
2000-12-02  0:30               ` corruption kumon
2000-12-02  3:59             ` corruption Andrew Morton
2000-12-02 14:00               ` corruption Andrew Morton
2000-12-02 15:33                 ` corruption Alexander Viro
2000-12-02 16:39                   ` corruption Petr Vandrovec
2000-12-02 17:50                     ` corruption Alexander Viro
2000-12-02 17:59                     ` corruption Alexander Viro
2000-12-03 20:24                       ` corruption Jonathan Hudson
2000-12-03 21:44                   ` corruption Andrew Morton
2000-12-03 22:45                     ` [resync?] corruption Alexander Viro
2000-12-04  0:56                       ` Jeff V. Merkey [this message]
2000-12-04 15:00                   ` corruption Stephen C. Tweedie
2000-12-04 15:19                     ` corruption Alexander Viro
2000-12-01 17:29           ` corruption Jeff Garzik

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=20001203175610.A24729@vger.timpanogas.org \
    --to=jmerkey@vger.timpanogas.org \
    --cc=andrewm@uow.edu.au \
    --cc=jonathan@daria.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sct@redhat.com \
    --cc=torvalds@transmeta.com \
    --cc=vandrove@vc.cvut.cz \
    --cc=viro@math.psu.edu \
    /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