1. 01 7月, 2012 3 次提交
  2. 08 6月, 2012 2 次提交
    • T
      ext4: don't set i_flags in EXT4_IOC_SETFLAGS · b22b1f17
      Tao Ma 提交于
      Commit 79906964 uses the ext4_{set,clear}_inode_flags() functions to
      change the i_flags automatically but fails to remove the error setting
      of i_flags.  So we still have the problem of trashing state flags.
      Fix this by removing the assignment.
      Signed-off-by: NTao Ma <boyu.mt@taobao.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      b22b1f17
    • T
      ext4: fix the free blocks calculation for ext3 file systems w/ uninit_bg · b0dd6b70
      Theodore Ts'o 提交于
      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 fd034a84, present since v3.2).
      Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
      Reported-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Tested-by: NKees Cook <keescook@chromium.org>
      Cc: stable@kernel.org
      b0dd6b70
  3. 01 6月, 2012 5 次提交
  4. 31 5月, 2012 2 次提交
  5. 29 5月, 2012 11 次提交
  6. 27 5月, 2012 2 次提交
  7. 21 5月, 2012 1 次提交
    • T
      ext4: enable the 64-bit jbd2 feature based on the 64-bit ext4 feature · f32aaf2d
      Theodore Ts'o 提交于
      Previously we were only enabling the 64-bit jbd2 feature if the number
      of blocks in the file system was greater 2**32-1.  The problem with
      this is that it makes it harder to test the 64-bit journal code paths
      with small file systems, since a small test file system would with the
      64-bit ext4 feature enable would use a 64-bit file system on-disk data
      structures, but use a 32-bit journal.
      
      This would also cause problems when trying to do an online resize to
      grow the filesystem above the 2**32-1 boundary.  Fortunately the patch
      to support online resize for 64-bit file systems hasn't been merged
      yet, so this problem hasn't arisen in practice.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      f32aaf2d
  8. 16 5月, 2012 2 次提交
  9. 11 5月, 2012 1 次提交
    • L
      vfs: make it possible to access the dentry hash/len as one 64-bit entry · 26fe5750
      Linus Torvalds 提交于
      This allows comparing hash and len in one operation on 64-bit
      architectures.  Right now only __d_lookup_rcu() takes advantage of this,
      since that is the case we care most about.
      
      The use of anonymous struct/unions hides the alternate 64-bit approach
      from most users, the exception being a few cases where we initialize a
      'struct qstr' with a static initializer.  This makes the problematic
      cases use a new QSTR_INIT() helper function for that (but initializing
      just the name pointer with a "{ .name = xyzzy }" initializer remains
      valid, as does just copying another qstr structure).
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26fe5750
  10. 06 5月, 2012 1 次提交
  11. 30 4月, 2012 10 次提交