1. 14 7月, 2012 1 次提交
    • A
      stop passing nameidata to ->lookup() · 00cd8dd3
      Al Viro 提交于
      Just the flags; only NFS cares even about that, but there are
      legitimate uses for such argument.  And getting rid of that
      completely would require splitting ->lookup() into a couple
      of methods (at least), so let's leave that alone for now...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      00cd8dd3
  2. 21 3月, 2012 1 次提交
  3. 04 1月, 2012 1 次提交
    • A
      vfs: fix the stupidity with i_dentry in inode destructors · 6b520e05
      Al Viro 提交于
      Seeing that just about every destructor got that INIT_LIST_HEAD() copied into
      it, there is no point whatsoever keeping this INIT_LIST_HEAD in inode_init_once();
      the cost of taking it into inode_init_always() will be negligible for pipes
      and sockets and negative for everything else.  Not to mention the removal of
      boilerplate code from ->destroy_inode() instances...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6b520e05
  4. 02 11月, 2011 1 次提交
  5. 18 8月, 2011 1 次提交
  6. 31 3月, 2011 1 次提交
  7. 10 3月, 2011 1 次提交
  8. 14 1月, 2011 1 次提交
  9. 07 1月, 2011 1 次提交
    • N
      fs: icache RCU free inodes · fa0d7e3d
      Nick Piggin 提交于
      RCU free the struct inode. This will allow:
      
      - Subsequent store-free path walking patch. The inode must be consulted for
        permissions when walking, so an RCU inode reference is a must.
      - sb_inode_list_lock to be moved inside i_lock because sb list walkers who want
        to take i_lock no longer need to take sb_inode_list_lock to walk the list in
        the first place. This will simplify and optimize locking.
      - Could remove some nested trylock loops in dcache code
      - Could potentially simplify things a bit in VM land. Do not need to take the
        page lock to follow page->mapping.
      
      The downsides of this is the performance cost of using RCU. In a simple
      creat/unlink microbenchmark, performance drops by about 10% due to inability to
      reuse cache-hot slab objects. As iterations increase and RCU freeing starts
      kicking over, this increases to about 20%.
      
      In cases where inode lifetimes are longer (ie. many inodes may be allocated
      during the average life span of a single inode), a lot of this cache reuse is
      not applicable, so the regression caused by this patch is smaller.
      
      The cache-hot regression could largely be avoided by using SLAB_DESTROY_BY_RCU,
      however this adds some complexity to list walking and store-free path walking,
      so I prefer to implement this at a later date, if it is shown to be a win in
      real situations. I haven't found a regression in any non-micro benchmark so I
      doubt it will be a problem.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      fa0d7e3d
  10. 29 10月, 2010 1 次提交
  11. 17 6月, 2010 1 次提交
  12. 07 2月, 2010 1 次提交
  13. 24 9月, 2009 1 次提交
    • T
      fs: Make unload_nls() NULL pointer safe · 6d729e44
      Thomas Gleixner 提交于
      Most call sites of unload_nls() do:
      	if (nls)
      		unload_nls(nls);
      
      Check the pointer inside unload_nls() like we do in kfree() and
      simplify the call sites.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Steve French <sfrench@us.ibm.com>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6d729e44
  14. 22 9月, 2009 1 次提交
  15. 17 6月, 2009 1 次提交
  16. 16 6月, 2009 1 次提交
    • A
      NLS: update handling of Unicode · 74675a58
      Alan Stern 提交于
      This patch (as1239) updates the kernel's treatment of Unicode.  The
      character-set conversion routines are well behind the current state of
      the Unicode specification: They don't recognize the existence of code
      points beyond plane 0 or of surrogate pairs in the UTF-16 encoding.
      
      The old wchar_t 16-bit type is retained because it's still used in
      lots of places.  This shouldn't cause any new problems; if a
      conversion now results in an invalid 16-bit code then before it must
      have yielded an undefined code.
      
      Difficult-to-read names like "utf_mbstowcs" are replaced with more
      transparent names like "utf8s_to_utf16s" and the ordering of the
      parameters is rationalized (buffer lengths come immediate after the
      pointers they refer to, and the inputs precede the outputs).
      Fortunately the low-level conversion routines are used in only a few
      places; the interfaces to the higher-level uni2char and char2uni
      methods have been left unchanged.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      74675a58
  17. 12 6月, 2009 1 次提交
    • C
      push BKL down into ->put_super · 6cfd0148
      Christoph Hellwig 提交于
      Move BKL into ->put_super from the only caller.  A couple of
      filesystems had trivial enough ->put_super (only kfree and NULLing of
      s_fs_info + stuff in there) to not get any locking: coda, cramfs, efs,
      hugetlbfs, omfs, qnx4, shmem, all others got the full treatment.  Most
      of them probably don't need it, but I'd rather sort that out individually.
      Preferably after all the other BKL pushdowns in that area.
      
      [AV: original used to move lock_super() down as well; these changes are
      removed since we don't do lock_super() at all in generic_shutdown_super()
      now]
      [AV: fuse, btrfs and xfs are known to need no damn BKL, exempt]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6cfd0148
  18. 03 4月, 2009 1 次提交
  19. 01 1月, 2009 1 次提交
  20. 17 10月, 2008 1 次提交
    • H
      befs: annotate fs32 on tests for superblock endianness · 152b95a1
      Harvey Harrison 提交于
      Does compile-time byteswapping rather than runtime.
      
      Noticed by sparse:
      fs/befs/super.c:29:6: warning: cast to restricted __le32
      fs/befs/super.c:29:6: warning: cast from restricted fs32
      fs/befs/super.c:31:11: warning: cast to restricted __be32
      fs/befs/super.c:31:11: warning: cast from restricted fs32
      fs/befs/super.c:31:11: warning: cast to restricted __be32
      fs/befs/super.c:31:11: warning: cast from restricted fs32
      fs/befs/super.c:31:11: warning: cast to restricted __be32
      fs/befs/super.c:31:11: warning: cast from restricted fs32
      fs/befs/super.c:31:11: warning: cast to restricted __be32
      fs/befs/super.c:31:11: warning: cast from restricted fs32
      fs/befs/super.c:31:11: warning: cast to restricted __be32
      fs/befs/super.c:31:11: warning: cast from restricted fs32
      fs/befs/super.c:31:11: warning: cast to restricted __be32
      fs/befs/super.c:31:11: warning: cast from restricted fs32
      fs/befs/linuxvfs.c:811:7: warning: cast to restricted __le32
      fs/befs/linuxvfs.c:811:7: warning: cast from restricted fs32
      fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32
      fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32
      fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32
      fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32
      fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32
      fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32
      fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32
      fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32
      fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32
      fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32
      fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32
      fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Cc: "Sergey S. Kostyliov" <rathamahata@php4.ru>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      152b95a1
  21. 14 10月, 2008 1 次提交
  22. 25 8月, 2008 1 次提交
  23. 27 7月, 2008 1 次提交
  24. 29 4月, 2008 1 次提交
  25. 09 2月, 2008 1 次提交
  26. 08 2月, 2008 1 次提交
  27. 17 10月, 2007 1 次提交
  28. 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
  29. 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
  30. 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
  31. 13 2月, 2007 1 次提交
  32. 09 12月, 2006 1 次提交
  33. 08 12月, 2006 2 次提交
  34. 11 10月, 2006 1 次提交
  35. 27 9月, 2006 2 次提交
  36. 06 8月, 2006 1 次提交
    • D
      [PATCH] Fix BeFS slab corruption · 94f563c4
      Diego Calleja 提交于
      In bugzilla #6941, Jens Kilian reported:
      
      "The function befs_utf2nls (in fs/befs/linuxvfs.c) writes a 0 byte past the
      end of a block of memory allocated via kmalloc(), leading to memory
      corruption.  This happens only for filenames which are pure ASCII and a
      multiple of 4 bytes in length.  [...]
      
      Without DEBUG_SLAB, this leads to further corruption and hard lockups; I
      believe this is the bug which has made kernels later than 2.6.8 unusable
      for me.  (This must be due to changes in memory management, the bug has
      been in the BeFS driver since the time it was introduced (AFAICT).)
      
      Steps to reproduce:
      Create a directory (in BeOS, naturally :-) with files named, e.g.,
      "1", "22", "333", "4444", ...  Mount it in Linux and do an "ls" or "find""
      
      This patch implements the suggested fix. Credits to Jens Kilian for
      debugging the problem and finding the right fix.
      Signed-off-by: NDiego Calleja <diegocg@gmail.com>
      Cc: Jens Kilian <jjk@acm.org>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      94f563c4
  37. 01 7月, 2006 1 次提交
  38. 29 6月, 2006 1 次提交