user/sven/linux.git, branch v2.6.29.5

Linux 2.6.29.5

2009-06-15T16:44:45Z

ext4: Fix race in ext4_inode_info.i_cached_extent

2009-06-15T16:40:39Z

(cherry picked from commit 2ec0ae3acec47f628179ee95fe2c4da01b5e9fc4) If two CPU's simultaneously call ext4_ext_get_blocks() at the same time, there is nothing protecting the i_cached_extent structure from being used and updated at the same time. This could potentially cause the wrong location on disk to be read or written to, including potentially causing the corruption of the block group descriptors and/or inode table. This bug has been in the ext4 code since almost the very beginning of ext4's development. Fortunately once the data is stored in the page cache cache, ext4_get_blocks() doesn't need to be called, so trying to replicate this problem to the point where we could identify its root cause was *extremely* difficult. Many thanks to Kevin Shanahan for working over several months to be able to reproduce this easily so we could finally nail down the cause of the corruption. Signed-off-by: "Theodore Ts'o" Reviewed-by: "Aneesh Kumar K.V" Signed-off-by: Greg Kroah-Hartman

ext4: Clear the unwritten buffer_head flag after the extent is initialized

2009-06-15T16:40:39Z

(cherry picked from commit 2a8964d63d50dd2d65d71d342bc7fb6ef4117614) The BH_Unwritten flag indicates that the buffer is allocated on disk but has not been written; that is, the disk was part of a persistent preallocation area. That flag should only be set when a get_blocks() function is looking up a inode's logical to physical block mapping. When ext4_get_blocks_wrap() is called with create=1, the uninitialized extent is converted into an initialized one, so the BH_Unwritten flag is no longer appropriate. Hence, we need to make sure the BH_Unwritten is not left set, since the combination of BH_Mapped and BH_Unwritten is not allowed; among other things, it will result ext4's get_block() to be called over and over again during the write_begin phase of write(2). Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Use a fake block number for delayed new buffer_head

2009-06-15T16:40:37Z

(cherry picked from commit 33b9817e2ae097c7b8d256e3510ac6c54fc6d9d0) Use a very large unsigned number (~0xffff) as as the fake block number for the delayed new buffer. The VFS should never try to write out this number, but if it does, this will make it obvious. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Fix sub-block zeroing for writes into preallocated extents

2009-06-15T16:40:36Z

(cherry picked from commit 9c1ee184a30394e54165fa4c15923cabd952c106) We need to mark the buffer_head mapping preallocated space as new during write_begin. Otherwise we don't zero out the page cache content properly for a partial write. This will cause file corruption with preallocation. Now that we mark the buffer_head new we also need to have a valid buffer_head blocknr so that unmap_underlying_metadata() unmaps the correct block. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Ignore i_file_acl_high unless EXT4_FEATURE_INCOMPAT_64BIT is present

2009-06-15T16:40:36Z

(cherry picked from commit a9e817425dc0baede8ebe5fbc9984a640257432b) Don't try to look at i_file_acl_high unless the INCOMPAT_64BIT feature bit is set. The field is normally zero, but older versions of e2fsck didn't automatically check to make sure of this, so in the spirit of "be liberal in what you accept", don't look at i_file_acl_high unless we are using a 64-bit filesystem. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Fix softlockup caused by illegal i_file_acl value in on-disk inode

2009-06-15T16:40:35Z

(cherry picked from commit 485c26ec70f823f2a9cf45982b724893e53a859e) If the block containing external extended attributes (which is stored in i_file_acl and i_file_acl_high) is larger than the on-disk filesystem, the process which tried to access the extended attributes will endlessly issue kernel printks complaining that "__find_get_block_slow() failed", locking up that CPU until the system is forcibly rebooted. So when we read in the inode, make sure the i_file_acl value is legal, and if not, flag the filesystem as being corrupted. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: really print the find_group_flex fallback warning only once

2009-06-15T16:40:35Z

(cherry picked from commit 6b82f3cb2d480b7714eb0ff61aee99c22160389e) Missing braces caused the warning to print more than once. Signed-Off-By: Chuck Ebbert Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

jbd2: Update locking coments

2009-06-15T16:40:34Z

(cherry picked from commit 86db97c87f744364d5889ca8a4134ca2048b8f83) Update information about locking in JBD2 revoke code. Inconsistency in comments found by Lin Tan CC: Lin Tan Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Check for an valid i_mode when reading the inode from disk

2009-06-15T16:40:34Z

(cherry picked from commit 563bdd61fe4dbd6b58cf7eb06f8d8f14479ae1dc) Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman