1. 30 11月, 2007 1 次提交
  2. 15 11月, 2007 1 次提交
  3. 14 11月, 2007 1 次提交
    • L
      Revert "ext2/ext3/ext4: add block bitmap validation" · 0b832a4b
      Linus Torvalds 提交于
      This reverts commit 7c9e69fa, fixing up
      conflicts in fs/ext4/balloc.c manually.
      
      The cost of doing the bitmap validation on each lookup - even when the
      bitmap is cached - is absolutely prohibitive.  We could, and probably
      should, do it only when adding the bitmap to the buffer cache.  However,
      right now we are better off just reverting it.
      
      Peter Zijlstra measured the cost of this extra validation as a 85%
      decrease in cached iozone, and while I had a patch that took it down to
      just 17% by not being _quite_ so stupid in the validation, it was still
      a big slowdown that could have been avoided by just doing it right.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Andreas Dilger <adilger@clusterfs.com>
      Cc: Mingming Cao <cmm@us.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b832a4b
  4. 22 10月, 2007 3 次提交
  5. 17 10月, 2007 12 次提交
  6. 27 7月, 2007 1 次提交
    • E
      fix inode_table test in ext234_check_descriptors · 780dcdb2
      Eric Sandeen 提交于
      ext[234]_check_descriptors sanity checks block group descriptor geometry at
      mount time, testing whether the block bitmap, inode bitmap, and inode table
      reside wholly within the blockgroup.  However, the inode table test is off
      by one so that if the last block in the inode table resides on the last
      block of the block group, the test incorrectly fails.  This is because it
      tests the last block as (start + length) rather than (start + length - 1).
      
      This can be seen by trying to mount a filesystem made such as:
      
       mkfs.ext2 -F -b 1024 -m 0 -g 256 -N 3744 fsfile 1024
      
      which yields:
      
       EXT2-fs error (device loop0): ext2_check_descriptors: Inode table for group 0 not in group (block 101)!
       EXT2-fs: group descriptors corrupted!
      
      There is a similar bug in e2fsprogs, patch already sent for that.
      
      (I wonder if inside(), outside(), and/or in_range() should someday be
      used in this and other tests throughout the ext filesystems...)
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      780dcdb2
  7. 20 7月, 2007 2 次提交
  8. 18 7月, 2007 2 次提交
  9. 17 7月, 2007 2 次提交
  10. 10 7月, 2007 2 次提交
    • C
      xip sendfile removal · d054fe3d
      Carsten Otte 提交于
      This patch removes xip_file_sendfile, the sendfile implementation for
      xip without replacement. Those customers that use xip on s390 are not
      using sendfile() as far as we know, and so far s390 is the only platform
      this could potentially be used on so far.
      Having sendfile is not a popular feature for execute in place file
      systems, however we have a working implementation of splice_read() based
      on fs/splice.c if anyone asks for it.
      At this point in time, it does not seem preferable to merge
      splice_read() for xip because it causes extra maintenence effort due to
      code duplication and it requires struct page behind the xip memory
      segment. We'd like to get rid of that in favor of supporting flash based
      embedded platforms (Monta Vista work) soon.
      Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      d054fe3d
    • J
      sendfile: remove .sendfile from filesystems that use generic_file_sendfile() · 5ffc4ef4
      Jens Axboe 提交于
      They can use generic_file_splice_read() instead. Since sys_sendfile() now
      prefers that, there should be no change in behaviour.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      5ffc4ef4
  11. 29 6月, 2007 1 次提交
  12. 24 6月, 2007 1 次提交
  13. 17 5月, 2007 1 次提交
    • C
      Remove SLAB_CTOR_CONSTRUCTOR · a35afb83
      Christoph Lameter 提交于
      SLAB_CTOR_CONSTRUCTOR is always specified. No point in checking it.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Dave Kleikamp <shaggy@austin.ibm.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Jan Kara <jack@ucw.cz>
      Cc: David Chinner <dgc@sgi.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a35afb83
  14. 09 5月, 2007 3 次提交
  15. 08 5月, 2007 2 次提交
    • C
      slab allocators: Remove SLAB_DEBUG_INITIAL flag · 50953fe9
      Christoph Lameter 提交于
      I have never seen a use of SLAB_DEBUG_INITIAL.  It is only supported by
      SLAB.
      
      I think its purpose was to have a callback after an object has been freed
      to verify that the state is the constructor state again?  The callback is
      performed before each freeing of an object.
      
      I would think that it is much easier to check the object state manually
      before the free.  That also places the check near the code object
      manipulation of the object.
      
      Also the SLAB_DEBUG_INITIAL callback is only performed if the kernel was
      compiled with SLAB debugging on.  If there would be code in a constructor
      handling SLAB_DEBUG_INITIAL then it would have to be conditional on
      SLAB_DEBUG otherwise it would just be dead code.  But there is no such code
      in the kernel.  I think SLUB_DEBUG_INITIAL is too problematic to make real
      use of, difficult to understand and there are easier ways to accomplish the
      same effect (i.e.  add debug code before kfree).
      
      There is a related flag SLAB_CTOR_VERIFY that is frequently checked to be
      clear in fs inode caches.  Remove the pointless checks (they would even be
      pointless without removeal of SLAB_DEBUG_INITIAL) from the fs constructors.
      
      This is the last slab flag that SLUB did not support.  Remove the check for
      unimplemented flags from SLUB.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      50953fe9
    • N
      mm: make read_cache_page synchronous · 6fe6900e
      Nick Piggin 提交于
      Ensure pages are uptodate after returning from read_cache_page, which allows
      us to cut out most of the filesystem-internal PageUptodate calls.
      
      I didn't have a great look down the call chains, but this appears to fixes 7
      possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
      ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in
      block2mtd.  All depending on whether the filler is async and/or can return
      with a !uptodate page.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Hugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6fe6900e
  16. 21 2月, 2007 1 次提交
  17. 13 2月, 2007 2 次提交
  18. 12 2月, 2007 2 次提交