1. 22 10月, 2012 1 次提交
  2. 17 8月, 2012 1 次提交
  3. 31 7月, 2012 1 次提交
    • A
      ext4: use memweight() · 6017b485
      Akinobu Mita 提交于
      Convert ext4_count_free() to use memweight() instead of table lookup
      based counting clear bits implementation.  This change only affects the
      code segments enabled by EXT4FS_DEBUG.
      
      Note that this memweight() call can't be replaced with a single
      bitmap_weight() call, although the pointer to the memory area is aligned
      to long-word boundary.  Because the size of the memory area may not be a
      multiple of BITS_PER_LONG, then it returns wrong value on big-endian
      architecture.
      
      This also includes the following change.
      
      - Remove unnecessary map == NULL check in ext4_count_free() which
        always takes non-null pointer as the memory area.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6017b485
  4. 10 7月, 2012 1 次提交
    • T
      ext4: fix overhead calculation used by ext4_statfs() · 952fc18e
      Theodore Ts'o 提交于
      Commit f975d6bc introduced bug which caused ext4_statfs() to
      miscalculate the number of file system overhead blocks.  This causes
      the f_blocks field in the statfs structure to be larger than it should
      be.  This would in turn cause the "df" output to show the number of
      data blocks in the file system and the number of data blocks used to
      be larger than they should be.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      952fc18e
  5. 01 7月, 2012 1 次提交
  6. 30 4月, 2012 2 次提交
  7. 05 11月, 2008 1 次提交
    • T
      ext4: Change unsigned long to unsigned int · 498e5f24
      Theodore Ts'o 提交于
      Convert the unsigned longs that are most responsible for bloating the
      stack usage on 64-bit systems.
      
      Nearly all places in the ext3/4 code which uses "unsigned long" is
      probably a bug, since on 32-bit systems a ulong a 32-bits, which means
      we are wasting stack space on 64-bit systems.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      498e5f24
  8. 09 9月, 2008 1 次提交
  9. 30 4月, 2008 1 次提交
  10. 17 10月, 2007 1 次提交
  11. 12 10月, 2006 3 次提交
  12. 27 9月, 2006 1 次提交
  13. 26 3月, 2006 1 次提交
  14. 11 1月, 2006 1 次提交
  15. 31 10月, 2005 1 次提交
    • B
      [PATCH] ext3: sparse fixes · 381be254
      Ben Dooks 提交于
      Fix warnings from sparse due to un-declared functions that should either
      have a header file or have been declared static
      
       fs/ext2/bitmap.c:14:15: warning: symbol 'ext2_count_free' was not declared. Should it be static?
       fs/ext2/namei.c:92:15: warning: symbol 'ext2_get_parent' was not declared. Should it be static?
       fs/ext3/bitmap.c:15:15: warning: symbol 'ext3_count_free' was not declared. Should it be static?
       fs/ext3/namei.c:1013:15: warning: symbol 'ext3_get_parent' was not declared. Should it be static?
       fs/ext3/xattr.c:214:1: warning: symbol 'ext3_xattr_block_get' was not declared. Should it be static?
       fs/ext3/xattr.c:358:1: warning: symbol 'ext3_xattr_block_list' was not declared. Should it be static?
       fs/ext3/xattr.c:630:1: warning: symbol 'ext3_xattr_block_find' was not declared. Should it be static?
       fs/ext3/xattr.c:863:1: warning: symbol 'ext3_xattr_ibody_find' was not declared. Should it be static?
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      381be254
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4