1. 05 9月, 2012 1 次提交
  2. 21 8月, 2012 1 次提交
  3. 31 7月, 2012 2 次提交
  4. 18 7月, 2012 1 次提交
  5. 14 7月, 2012 1 次提交
    • M
      nfs: clean up ->create in nfs_rpc_ops · 8867fe58
      Miklos Szeredi 提交于
      Don't pass nfs_open_context() to ->create().  Only the NFS4 implementation
      needed that and only because it wanted to return an open file using open
      intents.  That task has been replaced by ->atomic_open so it is not necessary
      anymore to pass the context to the create rpc operation.
      
      Despite nfs4_proc_create apparently being okay with a NULL context it Oopses
      somewhere down the call chain.  So allocate a context here.
      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>
      8867fe58
  6. 29 6月, 2012 6 次提交
  7. 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
  8. 28 4月, 2012 4 次提交
  9. 21 3月, 2012 4 次提交
  10. 07 12月, 2011 1 次提交
  11. 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
  12. 01 8月, 2011 1 次提交
  13. 25 3月, 2011 1 次提交
  14. 12 3月, 2011 1 次提交
  15. 24 10月, 2010 1 次提交
  16. 22 9月, 2010 1 次提交
  17. 18 9月, 2010 3 次提交
  18. 17 9月, 2010 1 次提交
  19. 15 5月, 2010 8 次提交