summaryrefslogtreecommitdiffstats
path: root/net
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2012-06-07 18:56:06 -0400
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2012-06-17 11:21:23 -0700
commitc573b3798f5fd9e24f9ec23a39c4915c6e024faf (patch)
treea62c1612ed42b718b5e803240210635d41abe735 /net
parentd913c02b0a172d5dca6280da5b17a407d69bbce4 (diff)
downloadlinux-stable-c573b3798f5fd9e24f9ec23a39c4915c6e024faf.tar.gz
linux-stable-c573b3798f5fd9e24f9ec23a39c4915c6e024faf.tar.bz2
linux-stable-c573b3798f5fd9e24f9ec23a39c4915c6e024faf.zip
ext4: fix the free blocks calculation for ext3 file systems w/ uninit_bg
commit b0dd6b70f0fda17ae9762fbb72d98e40a4f66556 upstream. Ext3 filesystems that are converted to use as many ext4 file system features as possible will enable uninit_bg to speed up e2fsck times. These file systems will have a native ext3 layout of inode tables and block allocation bitmaps (as opposed to ext4's flex_bg layout). Unfortunately, in these cases, when first allocating a block in an uninitialized block group, ext4 would incorrectly calculate the number of free blocks in that block group, and then errorneously report that the file system was corrupt: EXT4-fs error (device vdd): ext4_mb_generate_buddy:741: group 30, 32254 clusters in bitmap, 32258 in gd This problem can be reproduced via: mke2fs -q -t ext4 -O ^flex_bg /dev/vdd 5g mount -t ext4 /dev/vdd /mnt fallocate -l 4600m /mnt/test The problem was caused by a bone headed mistake in the check to see if a particular metadata block was part of the block group. Many thanks to Kees Cook for finding and bisecting the buggy commit which introduced this bug (commit fd034a84e1, present since v3.2). Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Reported-by: Kees Cook <keescook@chromium.org> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Tested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions