1. 08 5月, 2007 1 次提交
  2. 03 4月, 2007 1 次提交
  3. 02 3月, 2007 1 次提交
    • M
      [PATCH] ext[34]: EA block reference count racing fix · 8a2bfdcb
      Mingming Cao 提交于
      There are race issues around ext[34] xattr block release code.
      
      ext[34]_xattr_release_block() checks the reference count of xattr block
      (h_refcount) and frees that xattr block if it is the last one reference it.
       Unlike ext2, the check of this counter is unprotected by any lock.
      ext[34]_xattr_release_block() will free the mb_cache entry before freeing
      that xattr block.  There is a small window between the check for the re
      h_refcount ==1 and the call to mb_cache_entry_free().  During this small
      window another inode might find this xattr block from the mbcache and reuse
      it, racing a refcount updates.  The xattr block will later be freed by the
      first inode without notice other inode is still use it.  Later if that
      block is reallocated as a datablock for other file, then more serious
      problem might happen.
      
      We need put a lock around places checking the refount as well to avoid
      racing issue.  Another place need this kind of protection is in
      ext3_xattr_block_set(), where it will modify the xattr block content in-
      the-fly if the refcount is 1 (means it's the only inode reference it).
      
      This will also fix another issue: the xattr block may not get freed at all
      if no lock is to protect the refcount check at the release time.  It is
      possible that the last two inodes could release the shared xattr block at
      the same time.  But both of them think they are not the last one so only
      decreased the h_refcount without freeing xattr block at all.
      
      We need to call lock_buffer() after ext3_journal_get_write_access() to
      avoid deadlock (because the later will call lock_buffer()/unlock_buffer
      () as well).
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Cc: Andreas Gruenbacher <agruen@suse.de>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a2bfdcb
  4. 21 2月, 2007 1 次提交
  5. 18 2月, 2007 1 次提交
  6. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  7. 13 2月, 2007 2 次提交
  8. 12 2月, 2007 5 次提交
  9. 09 12月, 2006 2 次提交
  10. 08 12月, 2006 20 次提交
  11. 29 10月, 2006 1 次提交
    • R
      [PATCH] ext4: fix printk format warnings · 1939e49a
      Randy Dunlap 提交于
      fs/ext4/resize.c:72: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:76: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:81: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:85: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 5)
      fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 5)
      fs/ext4/resize.c:98: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:103: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:109: warning: long long unsigned int format, __u64 arg (arg 4)
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1939e49a
  12. 12 10月, 2006 4 次提交
    • A
      [PATCH] ext4 whitespace cleanups · 63f57933
      Andrew Morton 提交于
      Someone's tab key is emitting spaces.  Attempt to repair some of the damage.
      
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      63f57933
    • D
      [PATCH] ext4: errors behaviour fix · ceea16bf
      Dmitry Mishin 提交于
      Current error behaviour for ext2 and ext3 filesystems does not fully
      correspond to the documentation and should be fixed.
      
      According to man 8 mount, ext2 and ext3 file systems allow to set one of 3
      different on-errors behaviours:
      
        ---- start of quote man 8 mount ----
      
        errors=continue / errors=remount-ro / errors=panic
      
          Define the behaviour when an error is encountered.  (Either ignore
          errors and just mark the file system erroneous and continue, or remount
          the file system read-only, or panic and halt the system.) The default is
          set in the filesystem superblock, and can be changed using tune2fs(8).
      
        ---- end of quote ----
      
      However EXT3_ERRORS_CONTINUE is not read from the superblock, and thus
      ERRORS_CONT is not saved on the sbi->s_mount_opt.  It leads to the incorrect
      handle of errors on ext3.
      
      Then we've checked corresponding code in ext2 and discovered that it is buggy
      as well:
      
      - EXT2_ERRORS_CONTINUE is not read from the superblock (the same);
      
      - parse_option() does not clean the alternative values and thus something
        like (ERRORS_CONT|ERRORS_RO) can be set;
      
      - if options are omitted, parse_option() does not set any of these options.
      
      Therefore it is possible to set any combination of these options on the ext2:
      
      - none of them may be set: EXT2_ERRORS_CONTINUE on superblock / empty mount
        options;
      
      - any of them may be set using mount options;
      
      - 2 any options may be set: by using EXT2_ERRORS_RO/EXT2_ERRORS_PANIC on the
        superblock and other value in mount options;
      
      - and finally all three options may be set by adding third option in remount.
      
      Currently ext2 uses these values only in ext2_error() and it is not leading to
      any noticeable troubles.  However somebody may be discouraged when he will try
      to workaround EXT2_ERRORS_PANIC on the superblock by using errors=continue in
      mount options.
      
      This patch:
      
      EXT4_ERRORS_CONTINUE should be taken from the superblock as default value for
      error behaviour.
      Signed-off-by: NDmitry Mishin <dim@openvz.org>
      Acked-by: NVasily Averin <vvs@sw.ru>
      Acked-by: NKirill Korotaev <dev@openvz.org>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ceea16bf
    • A
      [PATCH] ext4: rename logic_sb_block · 70bbb3e0
      Andrew Morton 提交于
      I assume this means "logical sb block".  So call it that.
      
      I still don't understand the name though.  A block is a block.  What's
      different about this one?
      
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      70bbb3e0
    • A
      [PATCH] ext4 64 bit divide fix · f4e5bc24
      Andrew Morton 提交于
      With CONFIG_LBD=n, sector_div() expands to a plain old divide.  But ext4 is
      _not_ passing in a sector_t as the first argument, so...
      
      fs/built-in.o: In function `ext4_get_group_no_and_offset':
      fs/ext4/balloc.c:39: undefined reference to `__umoddi3'
      fs/ext4/balloc.c:41: undefined reference to `__udivdi3'
      fs/built-in.o: In function `find_group_orlov':
      fs/ext4/ialloc.c:278: undefined reference to `__udivdi3'
      fs/built-in.o: In function `ext4_fill_super':
      fs/ext4/super.c:1488: undefined reference to `__udivdi3'
      fs/ext4/super.c:1488: undefined reference to `__umoddi3'
      fs/ext4/super.c:1594: undefined reference to `__udivdi3'
      fs/ext4/super.c:1601: undefined reference to `__umoddi3'
      
      Fix that up by calling do_div() directly.
      
      Also cast the arg to u64.  do_div() is only defined on u64, and ext4_fsblk_t
      is supposed to be opaque.
      
      Note especially the changes to find_group_orlov().  It was attempting to do
      
      	do_div(int, unsigned long long);
      
      which is royally screwed up.  Switched it to plain old divide.
      
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f4e5bc24