1. 19 Jul, 2007 1 commit
  2. 18 Jul, 2007 16 commits
  3. 17 Jul, 2007 2 commits
  4. 16 Jul, 2007 6 commits
  5. 10 Jul, 2007 1 commit
  6. 24 Jun, 2007 1 commit
  7. 31 May, 2007 4 commits
  8. 17 May, 2007 1 commit
    • Christoph Lameter's avatar
      Remove SLAB_CTOR_CONSTRUCTOR · a35afb83
      Christoph Lameter authored
      SLAB_CTOR_CONSTRUCTOR is always specified. No point in checking it.
      Signed-off-by: default avatarChristoph 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  9. 08 May, 2007 3 commits
    • Randy Dunlap's avatar
      header cleaning: don't include smp_lock.h when not used · e63340ae
      Randy Dunlap authored
      Remove includes of <linux/smp_lock.h> where it is not used/needed.
      Suggested by Al Viro.
      Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
      sparc64, and arm (all 59 defconfigs).
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Dmitriy Monakhov's avatar
      ext3: dirindex error pointer issues · fedee54d
      Dmitriy Monakhov authored
      - ext3_dx_find_entry() exit with out setting proper error pointer
      - do_split() exit with out setting proper error pointer
        it is realy painful because many callers contain folowing code:
                de = do_split(handle,dir, &bh, frame, &hinfo, &retval);
                if (!(de))
                             return retval;
                <<< WOW retval wasn't changed by do_split(), so caller failed
                <<< but return SUCCESS :)
      - Rearrange do_split() error path. Current error path is realy ugly, all
        this up and down jump stuff doesn't make code easy to understand.
      [dmonakhov@sw.ru: fix annoying fake error messages]
      Signed-off-by: default avatarMonakhov Dmitriy <dmonakhov@openvz.org>
      Cc: Andreas Dilger <adilger@clusterfs.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarMonakhov Dmitriy <dmonakhov@openvz.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Markus Rechberger's avatar
      ext2/3/4: fix file date underflow on ext2 3 filesystems on 64 bit systems · 4d7bf11d
      Markus Rechberger authored
      Taken from http://bugzilla.kernel.org/show_bug.cgi?id=5079
      signed long ranges from -2.147.483.648 to 2.147.483.647 on x86 32bit
      10000011110110100100111110111101 .. -2,082,844,739
      10000011110110100100111110111101 ..  2,212,122,557 <- this currently gets
      stored on the disk but when converting it to a 64bit signed long value it loses
      its sign and becomes positive.
      Cc: Andreas Dilger <adilger@dilger.ca>
      Cc: <linux-ext4@vger.kernel.org>
      Andreas says:
      This patch is now treating timestamps with the high bit set as negative
      times (before Jan 1, 1970).  This means we lose 1/2 of the possible range
      of timestamps (lopping off 68 years before unix timestamp overflow -
      now only 30 years away :-) to handle the extremely rare case of setting
      timestamps into the distant past.
      If we are only interested in fixing the underflow case, we could just
      limit the values to 0 instead of storing negative values.  At worst this
      will skew the timestamp by a few hours for timezones in the far east
      (files would still show Jan 1, 1970 in "ls -l" output).
      That said, it seems 32-bit systems (mine at least) allow files to be set
      into the past (01/01/1907 works fine) so it seems this patch is bringing
      the x86_64 behaviour into sync with other kernels.
      On the plus side, we have a patch that is ready to add nanosecond timestamps
      to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so
      this extends the maximum date to 2242.
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 07 May, 2007 2 commits
    • Christoph Lameter's avatar
      slab allocators: Remove SLAB_DEBUG_INITIAL flag · 50953fe9
      Christoph Lameter authored
      I have never seen a use of SLAB_DEBUG_INITIAL.  It is only supported by
      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: default avatarChristoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Peter Zijlstra's avatar
      mm: remove destroy_dirty_buffers from invalidate_bdev() · f98393a6
      Peter Zijlstra authored
      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;
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  11. 02 Apr, 2007 1 commit
  12. 01 Mar, 2007 1 commit
    • Mingming Cao's avatar
      [PATCH] ext[34]: EA block reference count racing fix · 8a2bfdcb
      Mingming Cao authored
      There are race issues around ext[34] xattr block release code.
      ext[34]_xattr_release_block() checks the reference count of xattr block
      (h_refcount) and frees that xattr block if it is the last one reference it.
       Unlike ext2, the check of this counter is unprotected by any lock.
      ext[34]_xattr_release_block() will free the mb_cache entry before freeing
      that xattr block.  There is a small window between the check for the re
      h_refcount ==1 and the call to mb_cache_entry_free().  During this small
      window another inode might find this xattr block from the mbcache and reuse
      it, racing a refcount updates.  The xattr block will later be freed by the
      first inode without notice other inode is still use it.  Later if that
      block is reallocated as a datablock for other file, then more serious
      problem might happen.
      We need put a lock around places checking the refount as well to avoid
      racing issue.  Another place need this kind of protection is in
      ext3_xattr_block_set(), where it will modify the xattr block content in-
      the-fly if the refcount is 1 (means it's the only inode reference it).
      This will also fix another issue: the xattr block may not get freed at all
      if no lock is to protect the refcount check at the release time.  It is
      possible that the last two inodes could release the shared xattr block at
      the same time.  But both of them think they are not the last one so only
      decreased the h_refcount without freeing xattr block at all.
      We need to call lock_buffer() after ext3_journal_get_write_access() to
      avoid deadlock (because the later will call lock_buffer()/unlock_buffer
      () as well).
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Cc: Andreas Gruenbacher <agruen@suse.de>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  13. 21 Feb, 2007 1 commit