1. 09 2月, 2008 1 次提交
  2. 08 2月, 2008 1 次提交
  3. 07 2月, 2008 2 次提交
  4. 29 1月, 2008 1 次提交
  5. 18 12月, 2007 1 次提交
  6. 22 10月, 2007 2 次提交
  7. 19 10月, 2007 1 次提交
    • T
      ext3: support large blocksize up to PAGESIZE · 0f0a89eb
      Takashi Sato 提交于
      This patch set supports large block size(>4k, <=64k) in ext3 just enlarging
      the block size limit.  But it is NOT possible to have 64kB blocksize on
      ext3 without some changes to the directory handling code.  The reason is
      that an empty 64kB directory block would have a rec_len == (__u16)2^16 ==
      0, and this would cause an error to be hit in the filesystem.  The proposed
      solution is treat 64k rec_len with a an impossible value like rec_len =
      0xffff to handle this.
      
      The Patch-set consists of the following 2 patches.
        [1/2]  ext3: enlarge blocksize
               - Allow blocksize up to pagesize
      
        [2/2]  ext3: fix rec_len overflow
               - prevent rec_len from overflow with 64KB blocksize
      
      Now on 64k page ppc64 box runs with this patch set we could create a 64k
      block size ext3, and able to handle empty directory block.
      Signed-off-by: NTakashi Sato <sho@tnes.nec.co.jp>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Cc: <linux-ext4@vger.kernel.org>
      Acked-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0f0a89eb
  8. 17 10月, 2007 4 次提交
  9. 12 9月, 2007 1 次提交
  10. 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
  11. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt 提交于
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  12. 18 7月, 2007 1 次提交
  13. 17 7月, 2007 5 次提交
  14. 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
  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
    • P
      mm: remove destroy_dirty_buffers from invalidate_bdev() · f98393a6
      Peter Zijlstra 提交于
      Remove the destroy_dirty_buffers argument from invalidate_bdev(), it hasn't
      been used in 6 years (so akpm says).
      
      find * -name \*.[ch] | xargs grep -l invalidate_bdev |
      while read file; do
      	quilt add $file;
      	sed -ie 's/invalidate_bdev(\([^,]*\),[^)]*)/invalidate_bdev(\1)/g' $file;
      done
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f98393a6
  16. 13 2月, 2007 1 次提交
  17. 12 2月, 2007 2 次提交
    • H
      [PATCH] fix umask when noACL kernel meets extN tuned for ACLs · 2e7842b8
      Hugh Dickins 提交于
      Fix insecure default behaviour reported by Tigran Aivazian: if an ext2 or
      ext3 or ext4 filesystem is tuned to mount with "acl", but mounted by a
      kernel built without ACL support, then umask was ignored when creating
      inodes - though root or user has umask 022, touch creates files as 0666,
      and mkdir creates directories as 0777.
      
      This appears to have worked right until 2.6.11, when a fix to the default
      mode on symlinks (always 0777) assumed VFS applies umask: which it does,
      unless the mount is marked for ACLs; but ext[234] set MS_POSIXACL in
      s_flags according to s_mount_opt set according to def_mount_opts.
      
      We could revert to the 2.6.10 ext[234]_init_acl (adding an S_ISLNK test);
      but other filesystems only set MS_POSIXACL when ACLs are configured.  We
      could fix this at another level; but it seems most robust to avoid setting
      the s_mount_opt flag in the first place (at the expense of more ifdefs).
      
      Likewise don't set the XATTR_USER flag when built without XATTR support.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Andreas Gruenbacher <agruen@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2e7842b8
    • E
      [PATCH] ext3: refuse ro to rw remount of fs with orphan inodes · ea9a05a1
      Eric Sandeen 提交于
      In the rare case where we have skipped orphan inode processing due to a
      readonly block device, and the block device subsequently changes back to
      read-write, disallow a remount,rw transition of the filesystem when we have an
      unprocessed orphan inodes as this would corrupt the list.
      
      Ideally we should process the orphan inode list during the remount, but that's
      trickier, and this plugs the hole for now.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Cc: "Stephen C. Tweedie" <sct@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ea9a05a1
  18. 09 12月, 2006 1 次提交
    • D
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells 提交于
      This facility provides three entry points:
      
      	ilog2()		Log base 2 of unsigned long
      	ilog2_u32()	Log base 2 of u32
      	ilog2_u64()	Log base 2 of u64
      
      These facilities can either be used inside functions on dynamic data:
      
      	int do_something(long q)
      	{
      		...;
      		y = ilog2(x)
      		...;
      	}
      
      Or can be used to statically initialise global variables with constant values:
      
      	unsigned n = ilog2(27);
      
      When performing static initialisation, the compiler will report "error:
      initializer element is not constant" if asked to take a log of zero or of
      something not reducible to a constant.  They treat negative numbers as
      unsigned.
      
      When not dealing with a constant, they fall back to using fls() which permits
      them to use arch-specific log calculation instructions - such as BSR on
      x86/x86_64 or SCAN on FRV - if available.
      
      [akpm@osdl.org: MMC fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3
  19. 08 12月, 2006 4 次提交
  20. 12 10月, 2006 1 次提交
    • D
      [PATCH] ext3: errors behaviour fix · 2245d7c2
      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:
      
      EXT3_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>
      2245d7c2
  21. 27 9月, 2006 6 次提交