1. 17 10月, 2007 10 次提交
  2. 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
  3. 20 7月, 2007 2 次提交
  4. 18 7月, 2007 2 次提交
  5. 17 7月, 2007 2 次提交
  6. 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
  7. 29 6月, 2007 1 次提交
  8. 24 6月, 2007 1 次提交
  9. 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
  10. 09 5月, 2007 3 次提交
  11. 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
  12. 21 2月, 2007 1 次提交
  13. 13 2月, 2007 2 次提交
  14. 12 2月, 2007 2 次提交
  15. 09 12月, 2006 2 次提交
  16. 08 12月, 2006 5 次提交
  17. 12 10月, 2006 1 次提交
    • V
      [PATCH] ext2: errors behaviour fix · 5a2b4062
      Vasily Averin 提交于
      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:
      
      EXT2_ERRORS_CONTINUE should be read from the superblock as default value for
      error behaviour.  parse_option() should clean the alternative options and
      should not change default value taken from the superblock.
      Signed-off-by: NVasily Averin <vvs@sw.ru>
      Acked-by: NKirill Korotaev <dev@openvz.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5a2b4062