1. 13 4月, 2012 2 次提交
  2. 10 4月, 2012 1 次提交
    • B
      GFS2: Allow caching of rindex glock · ca9248d8
      Bob Peterson 提交于
      This patch allows caching of the rindex glock. We were previously
      setting the GL_NOCACHE bit when the glock was released. That forced
      the rindex inode to be invalidated, which caused us to re-read
      rindex at the next access. However, it caused the glock to be
      unnecessarily bounced around the cluster. This patch allows
      the glock to remain cached, but it still causes the rindex to be
      re-read once it has been written to by gfs2_grow.
      
      Ben and I have tested single-node gfs2_grow cases and I've tested
      clustered gfs2_grow cases on my four-node cluster.
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      ca9248d8
  3. 09 4月, 2012 1 次提交
    • A
      dentry leak in simple_fill_super() failure exit · 640946f2
      Al Viro 提交于
      d_genocide() does _not_ evict dentries; it just removes extra ref
      pinning each of those.  Normally it's followed by shrinking the
      tree (it's done just before generic_shutdown_super() by kill_litter_super()),
      but in case of simple_fill_super() nothing of that kind will follow.
      Just do shrink_dcache_parent() manually.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      640946f2
  4. 07 4月, 2012 1 次提交
    • L
      Make the "word-at-a-time" helper functions more commonly usable · f68e556e
      Linus Torvalds 提交于
      I have a new optimized x86 "strncpy_from_user()" that will use these
      same helper functions for all the same reasons the name lookup code uses
      them.  This is preparation for that.
      
      This moves them into an architecture-specific header file.  It's
      architecture-specific for two reasons:
      
       - some of the functions are likely to want architecture-specific
         implementations.  Even if the current code happens to be "generic" in
         the sense that it should work on any little-endian machine, it's
         likely that the "multiply by a big constant and shift" implementation
         is less than optimal for an architecture that has a guaranteed fast
         bit count instruction, for example.
      
       - I expect that if architectures like sparc want to start playing
         around with this, we'll need to abstract out a few more details (in
         particular the actual unaligned accesses).  So we're likely to have
         more architecture-specific stuff if non-x86 architectures start using
         this.
      
         (and if it turns out that non-x86 architectures don't start using
         this, then having it in an architecture-specific header is still the
         right thing to do, of course)
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f68e556e
  5. 06 4月, 2012 8 次提交
  6. 05 4月, 2012 1 次提交
  7. 04 4月, 2012 2 次提交
  8. 02 4月, 2012 2 次提交
  9. 01 4月, 2012 22 次提交