1. 31 7月, 2012 4 次提交
  2. 18 7月, 2012 1 次提交
  3. 29 6月, 2012 2 次提交
  4. 20 6月, 2012 1 次提交
  5. 01 6月, 2012 1 次提交
  6. 25 5月, 2012 2 次提交
  7. 20 5月, 2012 1 次提交
  8. 06 5月, 2012 1 次提交
  9. 02 5月, 2012 6 次提交
  10. 28 4月, 2012 1 次提交
    • F
      NFS: create struct nfs_commit_info · ea2cf228
      Fred Isaman 提交于
      It is COMMIT that is handled the most differently between
      the paged and direct paths.  Create a structure that encapsulates
      everything either path needs to know about the commit state.
      
      We could use void to hide some of the layout driver stuff, but
      Trond suggests pulling it out to ensure type checking, given the
      huge changes being made, and the fact that it doesn't interfere
      with other drivers.
      Signed-off-by: NFred Isaman <iisaman@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      ea2cf228
  11. 29 3月, 2012 1 次提交
  12. 21 3月, 2012 1 次提交
  13. 11 3月, 2012 1 次提交
  14. 07 3月, 2012 2 次提交
  15. 06 3月, 2012 1 次提交
  16. 03 3月, 2012 1 次提交
  17. 07 2月, 2012 3 次提交
  18. 01 2月, 2012 4 次提交
  19. 13 1月, 2012 1 次提交
  20. 08 1月, 2012 1 次提交
    • T
      NFSv4: Save the owner/group name string when doing open · 6926afd1
      Trond Myklebust 提交于
      ...so that we can do the uid/gid mapping outside the asynchronous RPC
      context.
      This fixes a bug in the current NFSv4 atomic open code where the client
      isn't able to determine what the true uid/gid fields of the file are,
      (because the asynchronous nature of the OPEN call denies it the ability
      to do an upcall) and so fills them with default values, marking the
      inode as needing revalidation.
      Unfortunately, in some cases, the VFS will do some additional sanity
      checks on the file, and may override the server's decision to allow
      the open because it sees the wrong owner/group fields.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6926afd1
  21. 04 1月, 2012 2 次提交
  22. 07 12月, 2011 1 次提交
  23. 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