linux, branch v2.6.28.7

Linux 2.6.28.7

2009-02-20T22:41:27Z

Fix longstanding "error: storage size of '__mod_dmi_device_table' isn't known"

2009-02-20T22:40:30Z

commit 40413dcb7b273bda681dca38e6ff0bbb3728ef11 upstream. gcc 3.4.6 doesn't like MODULE_DEVICE_TABLE(dmi, x) expansion enough to error out. Shut it up in a most simple way. Signed-off-by: Alexey Dobriyan Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ext4: Initialize the new group descriptor when resizing the filesystem

2009-02-20T22:40:29Z

(cherry picked from commit fdff73f094e7220602cc3f8959c7230517976412) Make sure all of the fields of the group descriptor are properly initialized. Previously, we allowed bg_flags field to be contain random garbage, which could trigger non-deterministic behavior, including a kernel OOPS. http://bugzilla.kernel.org/show_bug.cgi?id=12433 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

jbd2: On a __journal_expect() assertion failure printk "JBD2", not "EXT3-fs"

2009-02-20T22:40:28Z

(cherry picked from commit 08ec8c3878cea0bf91f2ba3c0badf44b383752d0) Otherwise it can be very confusing to find a "EXT3-fs: " failure in the middle of EXT4-fs failures, and it makes it harder to track the source of the failure. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Add sanity check to make_indexed_dir

2009-02-20T22:40:28Z

(cherry picked from commit e6b8bc09ba2075cd91fbffefcd2778b1a00bd76f) Make sure the rec_len field in the '..' entry is sane, lest we overrun the directory block and cause a kernel oops on a purposefully corrupted filesystem. Thanks to Sami Liedes for reporting this bug. http://bugzilla.kernel.org/show_bug.cgi?id=12430 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: only use i_size_high for regular files

2009-02-20T22:40:28Z

(cherry picked from commit 06a279d636734da32bb62dd2f7b0ade666f65d7c) Directories are not allowed to be bigger than 2GB, so don't use i_size_high for anything other than regular files. E2fsck should complain about these inodes, but the simplest thing to do for the kernel is to only use i_size_high for regular files. This prevents an intentially corrupted filesystem from causing the kernel to burn a huge amount of CPU and issuing error messages such as: EXT4-fs warning (device loop0): ext4_block_to_path: block 135090028 > max Thanks to David Maciejak from Fortinet's FortiGuard Global Security Research Team for reporting this issue. http://bugzilla.kernel.org/show_bug.cgi?id=12375 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Add sanity checks for the superblock before mounting the filesystem

2009-02-20T22:40:28Z

(cherry picked from commit 4ec110281379826c5cf6ed14735e47027c3c5765) This avoids insane superblock configurations that could lead to kernel oops due to null pointer derefences. http://bugzilla.kernel.org/show_bug.cgi?id=12371 Thanks to David Maciejak at Fortinet's FortiGuard Global Security Research Team who discovered this bug independently (but at approximately the same time) as Thiemo Nagel, who submitted the patch. Signed-off-by: Thiemo Nagel Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Fix s_dirty_blocks_counter if block allocation failed with nodelalloc

2009-02-20T22:40:27Z

(cherry picked from commit 0087d9fb3f29f59e8d42c8b058376d80e5adde4c) With nodelalloc option we need to update the dirty block counter on block allocation failure. This is needed because we increment the dirty block counter early in the block allocation phase. Without the patch s_dirty_blocks_counter goes wrong so that filesystem's free blocks decreases incorrectly. Tested-by: Akira Fujita Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Init the complete page while building buddy cache

2009-02-20T22:40:27Z

(cherry picked from commit 29eaf024980e07cc01f31ae4ea5d68c917f4b7da) We need to init the complete page during buddy cache init by setting the contents to '1'. Otherwise we can see the following errors after doing an online resize of the filesystem: EXT4-fs error (device sdb1): ext4_mb_mark_diskspace_used: Allocating block 1040385 in system zone of 127 group Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Don't allow new groups to be added during block allocation

2009-02-20T22:40:27Z

(cherry picked from commit 8556e8f3b6c4c11601ce1e9ea8090a6d8bd5daae) After we mark the blocks in the buddy cache as allocated, we need to ensure that we don't reinit the buddy cache until the block bitmap is updated. This commit achieves this by holding the group_info alloc_semaphore till ext4_mb_release_context Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman