1. 02 6月, 2012 1 次提交
    • M
      nfs: don't open in ->d_revalidate · 0ef97dcf
      Miklos Szeredi 提交于
      NFSv4 can't do reliable opens in d_revalidate, since it cannot know whether a
      mount needs to be followed or not.  It does check d_mountpoint() on the dentry,
      which can result in a weird error if the VFS found that the mount does not in
      fact need to be followed, e.g.:
      
        # mount --bind /mnt/nfs /mnt/nfs-clone
        # echo something > /mnt/nfs/tmp/bar
        # echo x > /tmp/file
        # mount --bind /tmp/file /mnt/nfs-clone/tmp/bar
        # cat  /mnt/nfs/tmp/bar
        cat: /mnt/nfs/tmp/bar: Not a directory
      
      Which should, by any sane filesystem, result in "something" being printed.
      
      So instead do the open in f_op->open() and in the unlikely case that the cached
      dentry turned out to be invalid, drop the dentry and return EOPENSTALE to let
      the VFS retry.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      CC: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      0ef97dcf
  2. 11 5月, 2012 1 次提交
    • L
      vfs: make it possible to access the dentry hash/len as one 64-bit entry · 26fe5750
      Linus Torvalds 提交于
      This allows comparing hash and len in one operation on 64-bit
      architectures.  Right now only __d_lookup_rcu() takes advantage of this,
      since that is the case we care most about.
      
      The use of anonymous struct/unions hides the alternate 64-bit approach
      from most users, the exception being a few cases where we initialize a
      'struct qstr' with a static initializer.  This makes the problematic
      cases use a new QSTR_INIT() helper function for that (but initializing
      just the name pointer with a "{ .name = xyzzy }" initializer remains
      valid, as does just copying another qstr structure).
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26fe5750
  3. 02 5月, 2012 1 次提交
    • T
      NFS: Adapt readdirplus to application usage patterns · d69ee9b8
      Trond Myklebust 提交于
      While the use of READDIRPLUS is significantly more efficient than
      READDIR followed by many LOOKUP calls, it is still less efficient
      than just READDIR if the attributes are not required.
      
      This patch tracks when lookups are attempted on the directory,
      and uses that information to selectively disable READDIRPLUS
      on that directory.
      The first 'readdir' call is always served using READDIRPLUS.
      Subsequent calls only use READDIRPLUS if there was a successful
      lookup or revalidation on a child in the mean time.
      
      Credit for the original idea should go to Neil Brown. See:
            http://www.spinics.net/lists/linux-nfs/msg19996.html
      However, the implementation in this patch differs from Neil's
      in that it focuses on tracking lookups rather than calls to
      stat().
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Neil Brown <neilb@suse.de>
      d69ee9b8
  4. 28 4月, 2012 1 次提交
  5. 20 4月, 2012 1 次提交
  6. 20 3月, 2012 1 次提交
  7. 03 3月, 2012 1 次提交
    • C
      NFS: Make nfs_cache_array.size a signed integer · 88b8e133
      Chuck Lever 提交于
      Eliminate a number of implicit type casts in comparisons, and these
      compiler warnings:
      
      fs/nfs/dir.c: In function ‘nfs_readdir_clear_array’:
      fs/nfs/dir.c:264:16: warning: comparison between signed and unsigned
      		integer expressions [-Wsign-compare]
      fs/nfs/dir.c: In function ‘nfs_readdir_search_for_cookie’:
      fs/nfs/dir.c:352:16: warning: comparison between signed and unsigned
      		integer expressions [-Wsign-compare]
      fs/nfs/dir.c: In function ‘nfs_do_filldir’:
      fs/nfs/dir.c:769:38: warning: comparison between signed and unsigned
      		integer expressions [-Wsign-compare]
      fs/nfs/dir.c:780:9: warning: comparison between signed and unsigned
      		integer expressions [-Wsign-compare]
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      88b8e133
  8. 01 2月, 2012 1 次提交
  9. 04 1月, 2012 4 次提交
  10. 05 11月, 2011 1 次提交
    • J
      nfs: when attempting to open a directory, fall back on normal lookup (try #5) · 1788ea6e
      Jeff Layton 提交于
      commit d953126a changed how nfs_atomic_lookup handles an -EISDIR return
      from an OPEN call. Prior to that patch, that caused the client to fall
      back to doing a normal lookup. When that patch went in, the code began
      returning that error to userspace. The d_revalidate codepath however
      never had the corresponding change, so it was still possible to end up
      with a NULL ctx->state pointer after that.
      
      That patch caused a regression. When we attempt to open a directory that
      does not have a cached dentry, that open now errors out with EISDIR. If
      you attempt the same open with a cached dentry, it will succeed.
      
      Fix this by reverting the change in nfs_atomic_lookup and allowing
      attempts to open directories to fall back to a normal lookup
      
      Also, add a NFSv4-specific f_ops->open routine that just returns
      -ENOTDIR. This should never be called if things are working properly,
      but if it ever is, then the dprintk may help in debugging.
      
      To facilitate this, a new file_operations field is also added to the
      nfs_rpc_ops struct.
      
      Cc: stable@kernel.org
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      1788ea6e
  11. 31 7月, 2011 2 次提交
  12. 21 7月, 2011 1 次提交
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik 提交于
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
      in fsync to make it less of a painful operation, so push down taking i_mutex and
      the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
      file systems can drop taking the i_mutex altogether it seems, like ext3 and
      ocfs2.  For correctness sake I just pushed everything down in all cases to make
      sure that we keep the current behavior the same for everybody, and then each
      individual fs maintainer can make up their mind about what to do from there.
      Thanks,
      Acked-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  13. 20 7月, 2011 9 次提交
  14. 30 5月, 2011 1 次提交
  15. 26 5月, 2011 3 次提交
  16. 25 5月, 2011 1 次提交
  17. 25 3月, 2011 1 次提交
  18. 24 3月, 2011 3 次提交
  19. 17 3月, 2011 1 次提交
    • A
      nfs: store devname at disconnected NFS roots · b1942c5f
      Al Viro 提交于
      part 2: make sure that disconnected roots have corresponding mnt_devname
      values stashed into them.
      
      Have nfs*_get_root() stuff a copy of devname into ->d_fsdata of the
      found root, provided that it is disconnected.
      
      Have ->d_release() free it when dentry goes away.
      
      Have the places where NFS uses ->d_fsdata for sillyrename (and that
      can *never* happen to a disconnected root - dentry will be attached
      to its parent) free old devname copies if they find those.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      b1942c5f
  20. 16 1月, 2011 1 次提交
  21. 14 1月, 2011 2 次提交
  22. 13 1月, 2011 1 次提交
  23. 11 1月, 2011 1 次提交
    • T
      NFS: Don't use vm_map_ram() in readdir · 6650239a
      Trond Myklebust 提交于
      vm_map_ram() is not available on NOMMU platforms, and causes trouble
      on incoherrent architectures such as ARM when we access the page data
      through both the direct and the virtual mapping.
      
      The alternative is to use the direct mapping to access page data
      for the case when we are not crossing a page boundary, but to copy
      the data into a linear scratch buffer when we are accessing data
      that spans page boundaries.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Tested-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Cc: stable@kernel.org  [2.6.37]
      6650239a