1. 11 9月, 2013 1 次提交
    • G
      super: fix calculation of shrinkable objects for small numbers · 55f841ce
      Glauber Costa 提交于
      The sysctl knob sysctl_vfs_cache_pressure is used to determine which
      percentage of the shrinkable objects in our cache we should actively try
      to shrink.
      
      It works great in situations in which we have many objects (at least more
      than 100), because the aproximation errors will be negligible.  But if
      this is not the case, specially when total_objects < 100, we may end up
      concluding that we have no objects at all (total / 100 = 0, if total <
      100).
      
      This is certainly not the biggest killer in the world, but may matter in
      very low kernel memory situations.
      Signed-off-by: NGlauber Costa <glommer@openvz.org>
      Reviewed-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Acked-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: Arve Hjønnevåg <arve@android.com>
      Cc: Carlos Maiolino <cmaiolino@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: J. Bruce Fields <bfields@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Kent Overstreet <koverstreet@google.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      55f841ce
  2. 06 9月, 2013 1 次提交
  3. 04 9月, 2013 1 次提交
  4. 30 8月, 2013 1 次提交
  5. 22 8月, 2013 7 次提交
  6. 21 8月, 2013 1 次提交
  7. 08 8月, 2013 1 次提交
  8. 10 7月, 2013 2 次提交
  9. 05 7月, 2013 1 次提交
  10. 04 7月, 2013 1 次提交
  11. 29 6月, 2013 1 次提交
  12. 09 6月, 2013 3 次提交
  13. 07 6月, 2013 2 次提交
  14. 26 3月, 2013 1 次提交
  15. 26 2月, 2013 1 次提交
    • J
      vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op · ecf3d1f1
      Jeff Layton 提交于
      The following set of operations on a NFS client and server will cause
      
          server# mkdir a
          client# cd a
          server# mv a a.bak
          client# sleep 30  # (or whatever the dir attrcache timeout is)
          client# stat .
          stat: cannot stat `.': Stale NFS file handle
      
      Obviously, we should not be getting an ESTALE error back there since the
      inode still exists on the server. The problem is that the lookup code
      will call d_revalidate on the dentry that "." refers to, because NFS has
      FS_REVAL_DOT set.
      
      nfs_lookup_revalidate will see that the parent directory has changed and
      will try to reverify the dentry by redoing a LOOKUP. That of course
      fails, so the lookup code returns ESTALE.
      
      The problem here is that d_revalidate is really a bad fit for this case.
      What we really want to know at this point is whether the inode is still
      good or not, but we don't really care what name it goes by or whether
      the dcache is still valid.
      
      Add a new d_op->d_weak_revalidate operation and have complete_walk call
      that instead of d_revalidate. The intent there is to allow for a
      "weaker" d_revalidate that just checks to see whether the inode is still
      good. This is also gives us an opportunity to kill off the FS_REVAL_DOT
      special casing.
      
      [AV: changed method name, added note in porting, fixed confusion re
      having it possibly called from RCU mode (it won't be)]
      
      Cc: NeilBrown <neilb@suse.de>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      ecf3d1f1
  16. 23 2月, 2013 1 次提交
  17. 04 1月, 2013 1 次提交
  18. 18 12月, 2012 1 次提交
  19. 15 12月, 2012 2 次提交
    • T
      NFS: nfs_lookup_revalidate should not trust an inode with i_nlink == 0 · 65a0c149
      Trond Myklebust 提交于
      If the inode has no links, then we should force a new lookup.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      65a0c149
    • T
      NFS: Fix calls to drop_nlink() · 1f018458
      Trond Myklebust 提交于
      It is almost always wrong for NFS to call drop_nlink() after removing a
      file. What we really want is to mark the inode's attributes for
      revalidation, and we want to ensure that the VFS drops it if we're
      reasonably sure that this is the final unlink().
      Do the former using the usual cache validity flags, and the latter
      by testing if inode->i_nlink == 1, and clearing it in that case.
      
      This also fixes the following warning reported by Neil Brown and
      Jeff Layton (among others).
      
      [634155.004438] WARNING:
      at /home/abuild/rpmbuild/BUILD/kernel-desktop-3.5.0/lin [634155.004442]
      Hardware name: Latitude E6510 [634155.004577]  crc_itu_t crc32c_intel
      snd_hwdep snd_pcm snd_timer snd soundcor [634155.004609] Pid: 13402, comm:
      bash Tainted: G        W    3.5.0-36-desktop # [634155.004611] Call Trace:
      [634155.004630]  [<ffffffff8100444a>] dump_trace+0xaa/0x2b0
      [634155.004641]  [<ffffffff815a23dc>] dump_stack+0x69/0x6f
      [634155.004653]  [<ffffffff81041a0b>] warn_slowpath_common+0x7b/0xc0
      [634155.004662]  [<ffffffff811832e4>] drop_nlink+0x34/0x40
      [634155.004687]  [<ffffffffa05bb6c3>] nfs_dentry_iput+0x33/0x70 [nfs]
      [634155.004714]  [<ffffffff8118049e>] dput+0x12e/0x230
      [634155.004726]  [<ffffffff8116b230>] __fput+0x170/0x230
      [634155.004735]  [<ffffffff81167c0f>] filp_close+0x5f/0x90
      [634155.004743]  [<ffffffff81167cd7>] sys_close+0x97/0x100
      [634155.004754]  [<ffffffff815c3b39>] system_call_fastpath+0x16/0x1b
      [634155.004767]  [<00007f2a73a0d110>] 0x7f2a73a0d10f
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org [3.3+]
      1f018458
  20. 30 11月, 2012 2 次提交
  21. 02 10月, 2012 1 次提交
    • W
      NFSv4: Add ACCESS operation to OPEN compound · 6168f62c
      Weston Andros Adamson 提交于
      The OPEN operation has no way to differentiate an open for read and an
      open for execution - both look like read to the server. This allowed
      users to read files that didn't have READ access but did have EXEC access,
      which is obviously wrong.
      
      This patch adds an ACCESS call to the OPEN compound to handle the
      difference between OPENs for reading and execution.  Since we're going
      through the trouble of calling ACCESS, we check all possible access bits
      and cache the results hopefully avoiding an ACCESS call in the future.
      Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6168f62c
  22. 31 7月, 2012 3 次提交
  23. 18 7月, 2012 3 次提交
  24. 14 7月, 2012 1 次提交