linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Nix <nix@esperi.org.uk>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org
Subject: Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
Date: Sun, 28 Oct 2012 21:00:13 -0400	[thread overview]
Message-ID: <20121029010012.GE9161@thunk.org> (raw)
In-Reply-To: <508C633F.4070100@redhat.com>

On Sat, Oct 27, 2012 at 05:42:07PM -0500, Eric Sandeen wrote:
> 
> It looks like the inode_bitmap_bh is being modified outside a transaction:
> 
>                 ret2 = ext4_test_and_set_bit(ino, inode_bitmap_bh->b_data);
> 
> It needs a get_write_access / handle_dirty_metadata pair around it.

Oops.   Nice catch!!

The patch isn't quite right, though.  We only want to call
ext4_journal_get_write_access() when we know that there is an available
bit in the bitmap.  (We could still lose the race, but in that case
the winner of the race probably grabbed the bitmap block first.)

Also, we only need to call ext4_handle_dirty_metadata() if we
successfully grab the bit in the bitmap.

So I suggest this patch instead:

commit 087eda81f1ac6a6a0394f781b44f1d555d8f64c6
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Sun Oct 28 20:59:57 2012 -0400

    ext4: fix unjournaled inode bitmap modification
    
    commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 modified this function
    such that the inode bitmap was being modified outside a transaction,
    which could lead to corruption, and was discovered when journal_checksum
    found a bad checksum in the journal.
    
    Reported-by: Nix <nix@esperi.org.uk>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: stable@vger.kernel.org

diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 4facdd2..575afac 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -725,6 +725,10 @@ repeat_in_this_group:
 				   "inode=%lu", ino + 1);
 			continue;
 		}
+		BUFFER_TRACE(inode_bitmap_bh, "get_write_access");
+		err = ext4_journal_get_write_access(handle, inode_bitmap_bh);
+		if (err)
+			goto fail;
 		ext4_lock_group(sb, group);
 		ret2 = ext4_test_and_set_bit(ino, inode_bitmap_bh->b_data);
 		ext4_unlock_group(sb, group);
@@ -738,6 +742,11 @@ repeat_in_this_group:
 	goto out;
 
 got:
+	BUFFER_TRACE(inode_bitmap_bh, "call ext4_handle_dirty_metadata");
+	err = ext4_handle_dirty_metadata(handle, NULL, inode_bitmap_bh);
+	if (err)
+		goto fail;
+
 	/* We may have to initialize the block bitmap if it isn't already */
 	if (ext4_has_group_desc_csum(sb) &&
 	    gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {

  reply	other threads:[~2012-10-29  1:00 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87objupjlr.fsf@spindle.srvr.nix>
     [not found] ` <20121023013343.GB6370@fieldses.org>
     [not found]   ` <87mwzdnuww.fsf@spindle.srvr.nix>
     [not found]     ` <20121023143019.GA3040@fieldses.org>
     [not found]       ` <874nllxi7e.fsf_-_@spindle.srvr.nix>
     [not found]         ` <874nllxi7e.fsf_-_-AdTWujXS48Mg67Zj9sPl2A@public.gmane.org>
2012-10-23 20:57           ` Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?) Nix
2012-10-23 22:19             ` Theodore Ts'o
2012-10-23 22:47               ` Nix
2012-10-23 23:16                 ` Theodore Ts'o
2012-10-23 23:06               ` Nix
2012-10-23 23:28                 ` Theodore Ts'o
2012-10-23 23:34                   ` Nix
2012-10-24  0:57               ` Eric Sandeen
2012-10-24 20:17                 ` Jan Kara
2012-10-26 15:25                   ` Eric Sandeen
2012-10-24 19:13               ` Jannis Achstetter
2012-10-24 21:31                 ` Theodore Ts'o
2012-10-24 22:05                   ` Jannis Achstetter
2012-10-24 23:47                   ` Nix
2012-10-25 17:02                   ` Felipe Contreras
     [not found]             ` <87pq48nbyz.fsf_-_-AdTWujXS48Mg67Zj9sPl2A@public.gmane.org>
2012-10-24  1:13               ` Eric Sandeen
2012-10-24  4:15                 ` Nix
2012-10-24  4:27                   ` Eric Sandeen
2012-10-24  5:23                     ` Theodore Ts'o
2012-10-24  7:00                       ` Hugh Dickins
2012-10-24 11:46                         ` Nix
2012-10-24 11:45                       ` Nix
2012-10-24 17:22                       ` Eric Sandeen
2012-10-24 19:49                       ` Nix
2012-10-24 19:54                         ` Nix
2012-10-24 20:30                         ` Eric Sandeen
2012-10-24 20:34                           ` Nix
2012-10-24 20:45                         ` Nix
2012-10-24 21:08                         ` Theodore Ts'o
2012-10-24 23:27                           ` Apparent serious progressive ext4 data corruption bug in 3.6 (when rebooting during umount) Nix
2012-10-24 23:42                             ` Nix
2012-10-25  1:10                             ` Theodore Ts'o
2012-10-25  1:45                               ` Nix
2012-10-25 14:12                                 ` Theodore Ts'o
2012-10-25 14:15                                   ` Nix
2012-10-25 17:39                                     ` Nix
2012-10-25 11:06                               ` Nix
2012-10-26  0:22                               ` Apparent serious progressive ext4 data corruption bug in 3.6 (when rebooting during umount) (possibly blockdev / arcmsr at fault??) Nix
2012-10-26 20:35             ` Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?) Eric Sandeen
2012-10-26 20:37               ` Nix
     [not found]                 ` <87wqydx957.fsf-AdTWujXS48Mg67Zj9sPl2A@public.gmane.org>
2012-10-26 20:56                   ` Theodore Ts'o
     [not found]                     ` <20121026205618.GC8614-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2012-10-26 20:59                       ` Nix
     [not found]                         ` <87objpx84k.fsf-AdTWujXS48Mg67Zj9sPl2A@public.gmane.org>
2012-10-26 21:15                           ` Theodore Ts'o
2012-10-26 21:19                             ` Nix
     [not found]                               ` <87haphx76u.fsf-AdTWujXS48Mg67Zj9sPl2A@public.gmane.org>
2012-10-27  0:22                                 ` Theodore Ts'o
2012-10-27 12:45                                   ` Nix
2012-10-27 17:55                                     ` Theodore Ts'o
2012-10-27 18:47                                       ` Nix
2012-10-27 21:19                                         ` Eric Sandeen
2012-10-27 21:21                                           ` Nix
2012-10-27 21:23                                             ` Eric Sandeen
2012-10-27 21:29                                               ` Nix
2012-10-27 21:34                                                 ` Eric Sandeen
2012-10-27 21:40                                                   ` Nix
     [not found]                                                   ` <09758CEA-74B5-48D0-8075-BB723A2CABBB@dilger.ca>
2012-10-29  2:09                                                     ` Eric Sandeen
2012-10-27 22:42                                           ` Eric Sandeen
2012-10-29  1:00                                             ` Theodore Ts'o [this message]
2012-10-29  1:04                                               ` Nix
2012-10-29  2:24                                               ` Eric Sandeen
2012-10-29  2:34                                                 ` Theodore Ts'o
2012-10-29  2:35                                                   ` Eric Sandeen
2012-10-29  2:42                                                     ` Theodore Ts'o
2012-10-27 18:30                                     ` Eric Sandeen
     [not found]                             ` <20121026211542.GE8614-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2012-10-27  3:11                               ` Jim Rees
2012-10-27  8:01               ` Testing ext4's journal via simulating a reboot via KVM Theodore Ts'o
2012-10-28  4:23             ` [PATCH] ext4: fix unjournaled inode bitmap modification Eric Sandeen
2012-10-28 13:59               ` Nix
2012-10-29  2:30               ` [PATCH -v3] " Theodore Ts'o
2012-10-29  3:24                 ` Eric Sandeen
2012-10-29  5:07                 ` Andreas Dilger
2012-10-29 17:08                 ` Darrick J. Wong
     [not found] <jXsTo-5lW-13@gated-at.bofh.it>
     [not found] ` <jXBDk-7vn-13@gated-at.bofh.it>
     [not found]   ` <jXNl8-5m5-13@gated-at.bofh.it>
     [not found]     ` <jXNOa-5MR-23@gated-at.bofh.it>
     [not found]       ` <jXPGh-87s-5@gated-at.bofh.it>
     [not found]         ` <jXTJW-4CH-55@gated-at.bofh.it>
     [not found]           ` <jXUZj-6mo-13@gated-at.bofh.it>
     [not found]             ` <jXVLH-7kO-5@gated-at.bofh.it>
     [not found]               ` <jXW53-7CC-5@gated-at.bofh.it>
     [not found]                 ` <jXWeJ-7Lk-1@gated-at.bofh.it>
2012-10-24 17:38                   ` Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?) Martin
2012-10-26 20:13                     ` Martin
2012-10-26 20:24                       ` Nix
2012-10-26 20:44                         ` Martin
2012-10-26 20:47                           ` Nix
2012-10-26 21:10                       ` Theodore Ts'o
2012-10-26 23:15                         ` Martin

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=20121029010012.GE9161@thunk.org \
    --to=tytso@mit.edu \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nix@esperi.org.uk \
    --cc=sandeen@redhat.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 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).