1. 24 6月, 2009 1 次提交
  2. 12 6月, 2009 4 次提交
  3. 18 5月, 2009 1 次提交
  4. 27 4月, 2009 1 次提交
  5. 26 3月, 2009 1 次提交
  6. 12 2月, 2009 1 次提交
    • C
      ext2/xip: refuse to change xip flag during remount with busy inodes · 0e4a9b59
      Carsten Otte 提交于
      For a reason that I was unable to understand in three months of debugging,
      mount ext2 -o remount stopped working properly when remounting from
      regular operation to xip, or the other way around.  According to a git
      bisect search, the problem was introduced with the VM_MIXEDMAP/PTE_SPECIAL
      rework in the vm:
      
      commit 70688e4d
      Author: Nick Piggin <npiggin@suse.de>
      Date:   Mon Apr 28 02:13:02 2008 -0700
      
          xip: support non-struct page backed memory
      
      In the failing scenario, the filesystem is mounted read only via root=
      kernel parameter on s390x.  During remount (in rc.sysinit), the inodes of
      the bash binary and its libraries are busy and cannot be invalidated (the
      bash which is running rc.sysinit resides on subject filesystem).
      Afterwards, another bash process (running ifup-eth) recurses into a
      subshell, runs dup_mm (via fork).  Some of the mappings in this bash
      process were created from inodes that could not be invalidated during
      remount.
      
      Both parent and child process crash some time later due to inconsistencies
      in their address spaces.  The issue seems to be timing sensitive, various
      attempts to recreate it have failed.
      
      This patch refuses to change the xip flag during remount in case some
      inodes cannot be invalidated.  This patch keeps users from running into
      that issue.
      
      [akpm@linux-foundation.org: cleanup]
      Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: Jared Hulbert <jaredeh@gmail.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0e4a9b59
  7. 09 1月, 2009 1 次提交
  8. 14 10月, 2008 1 次提交
  9. 27 7月, 2008 1 次提交
  10. 26 7月, 2008 1 次提交
  11. 28 4月, 2008 4 次提交
  12. 09 2月, 2008 1 次提交
  13. 08 2月, 2008 1 次提交
  14. 07 2月, 2008 3 次提交
  15. 29 1月, 2008 1 次提交
  16. 22 10月, 2007 2 次提交
  17. 17 10月, 2007 5 次提交
  18. 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
  19. 20 7月, 2007 2 次提交
  20. 18 7月, 2007 1 次提交
  21. 17 7月, 2007 1 次提交
  22. 29 6月, 2007 1 次提交
  23. 24 6月, 2007 1 次提交
  24. 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
  25. 08 5月, 2007 1 次提交
    • 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
  26. 13 2月, 2007 1 次提交