All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: ReiserFS Mailing List <reiserfs-list@namesys.com>
Subject: [PATCH] resize_reiserfs may use invalid bitmap blocks
Date: Mon, 19 Apr 2004 15:06:59 -0400	[thread overview]
Message-ID: <40842353.9090409@suse.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Another problem in reiserfs_resize:

This time it's the writing of the new bitmaps. It writes them outside of
~ journal control, which is fine. It does it synchronously, and if the
transaction following it doesn't complete, then the new bitmaps aren't
used anyway.

However, it doesn't check to see if the writing of the new bitmap blocks
succeeded, so the bitmaps may contain invalid data later on.

Attached is a patch that checks the error status of the bitmap block and
returns -EIO as appropriate.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAhCNSLPWxlyuTD7IRAjA9AKCkdFGco8nKraGP11pY7Ya0aMkA2wCeNSou
/A+i7SeSTDRzfeM6V36h1xc=
=9ZE9
-----END PGP SIGNATURE-----

[-- Attachment #2: reiserfs-resize-3.diff --]
[-- Type: text/plain, Size: 1157 bytes --]

diff -u linux-2.6.5.kgdb/fs/reiserfs/resize.c linux-2.6.5.kgdb.afs/fs/reiserfs/resize.c
--- linux-2.6.5.kgdb/fs/reiserfs/resize.c	2004-04-03 22:36:55.000000000 -0500
+++ linux-2.6.5.kgdb.afs/fs/reiserfs/resize.c	2004-04-19 15:01:44.923208976 -0400
 -113,6 +117,11 @@
 	    memset (bitmap, 0, sizeof (struct reiserfs_bitmap_info) * SB_BMAP_NR(s));
 	    for (i = 0; i < bmap_nr; i++)
 		bitmap[i] = SB_AP_BITMAP(s)[i];
+
+	    /* This doesn't go through the journal, but it doesn't have to.
+	     * The changes are still atomic: We're synced up when the journal
+	     * transaction begins, and the new bitmaps don't matter if the
+	     * transaction fails. */
 	    for (i = bmap_nr; i < bmap_nr_new; i++) {
 		bitmap[i].bh = sb_getblk(s, i * s->s_blocksize * 8);
 		memset(bitmap[i].bh->b_data, 0, sb_blocksize(sb));
@@ -121,6 +130,10 @@
 		set_buffer_uptodate(bitmap[i].bh);
 		mark_buffer_dirty(bitmap[i].bh) ;
 		sync_dirty_buffer(bitmap[i].bh);
+		if (!buffer_uptodate (bitmap[i].bh)) {
+		    vfree (bitmap);
+		    return -EIO;
+		}
 		// update bitmap_info stuff
 		bitmap[i].first_zero_hint=1;
 		bitmap[i].free_count = sb_blocksize(sb) * 8 - 1;

                 reply	other threads:[~2004-04-19 19:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=40842353.9090409@suse.com \
    --to=jeffm@suse.com \
    --cc=reiserfs-list@namesys.com \
    /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.