Message ID | 1410818997-9432-121-git-send-email-kamal@canonical.com |
---|---|
State | New |
Headers | show |
On Mon, 2014-09-15 at 15:08 -0700, Kamal Mostafa wrote: > 3.13.11.7 -stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Theodore Ts'o <tytso@mit.edu> > > commit 86f0afd463215fc3e58020493482faa4ac3a4d69 upstream. > > If there is a failure while allocating the preallocation structure, a > number of blocks can end up getting marked in the in-memory buddy > bitmap, and then not getting released. This can result in the > following corruption getting reported by the kernel: > > EXT4-fs error (device sda3): ext4_mb_generate_buddy:758: group 1126, > 12793 clusters in bitmap, 12729 in gd > > In that case, we need to release the blocks using mb_free_blocks(). > > Tested: fs smoke test; also demonstrated that with injected errors, > the file system is no longer getting corrupted > > Google-Bug-Id: 16657874 > > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> > Signed-off-by: Kamal Mostafa <kamal@canonical.com> [...] You need to apply commit c99d1e6e83b0 ("ext4: fix BUG_ON in mb_free_blocks()") along with this. Ben.
On Wed, 2014-09-17 at 12:13 +0100, Ben Hutchings wrote: > On Mon, 2014-09-15 at 15:08 -0700, Kamal Mostafa wrote: > > 3.13.11.7 -stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Theodore Ts'o <tytso@mit.edu> > > > > commit 86f0afd463215fc3e58020493482faa4ac3a4d69 upstream. > > > > If there is a failure while allocating the preallocation structure, a > > number of blocks can end up getting marked in the in-memory buddy > > bitmap, and then not getting released. This can result in the > > following corruption getting reported by the kernel: > > > > EXT4-fs error (device sda3): ext4_mb_generate_buddy:758: group 1126, > > 12793 clusters in bitmap, 12729 in gd > > > > In that case, we need to release the blocks using mb_free_blocks(). > > > > Tested: fs smoke test; also demonstrated that with injected errors, > > the file system is no longer getting corrupted > > > > Google-Bug-Id: 16657874 > > > > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> > > Signed-off-by: Kamal Mostafa <kamal@canonical.com> > [...] > > You need to apply commit c99d1e6e83b0 ("ext4: fix BUG_ON in > mb_free_blocks()") along with this. > > Ben. > Ok, that's now queued up for 3.13.11.7 also. Thanks again, Ben. -Kamal
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 502f0fd..795d5af 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -3196,8 +3196,27 @@ static void ext4_mb_collect_stats(struct ext4_allocation_context *ac) static void ext4_discard_allocated_blocks(struct ext4_allocation_context *ac) { struct ext4_prealloc_space *pa = ac->ac_pa; + struct ext4_buddy e4b; + int err; - if (pa && pa->pa_type == MB_INODE_PA) + if (pa == NULL) { + err = ext4_mb_load_buddy(ac->ac_sb, ac->ac_f_ex.fe_group, &e4b); + if (err) { + /* + * This should never happen since we pin the + * pages in the ext4_allocation_context so + * ext4_mb_load_buddy() should never fail. + */ + WARN(1, "mb_load_buddy failed (%d)", err); + return; + } + ext4_lock_group(ac->ac_sb, ac->ac_f_ex.fe_group); + mb_free_blocks(ac->ac_inode, &e4b, ac->ac_f_ex.fe_start, + ac->ac_f_ex.fe_len); + ext4_unlock_group(ac->ac_sb, ac->ac_f_ex.fe_group); + return; + } + if (pa->pa_type == MB_INODE_PA) pa->pa_free += ac->ac_b_ex.fe_len; }