An error occurred fetching the project authors.
  1. 04 Dec, 2009 1 commit
    • NeilBrown's avatar
      NFS4ERR_FILE_OPEN handling in Linux/NFS · 44ed3556
      NeilBrown authored
      NFS4ERR_FILE_OPEN is return by the server when an operation cannot be
      performed because the file is currently open and local (to the server)
      semantics prohibit the operation while the file is open.
      A typical case is a RENAME operation on an MS-Windows platform, which
      prevents rename while the file is open.
      
      While it is possible that such a condition is transitory, it is also
      very possible that the file will be held open for an extended period
      of time thus preventing the operation.
      
      The current behaviour of Linux/NFS is to retry the operation
      indefinitely.  This is not appropriate - we do not expect a rename to
      take an arbitrary amount of time to complete.
      
      Rather, and error should be returned.  The most obvious error code
      would be EBUSY, which is a legal at least for 'rename' and 'unlink',
      and accurately captures the reason for the error.
      
      This patch allows a few retries until about 2 seconds have elapsed,
      then returns EBUSY.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      44ed3556
  2. 11 Nov, 2009 1 commit
  3. 26 Oct, 2009 1 commit
  4. 23 Oct, 2009 1 commit
    • Trond Myklebust's avatar
      NFSv4: Fix a bug when the server returns NFS4ERR_RESOURCE · 52567b03
      Trond Myklebust authored
      RFC 3530 states that when we recieve the error NFS4ERR_RESOURCE, we are not
      supposed to bump the sequence number on OPEN, LOCK, LOCKU, CLOSE, etc
      operations. The problem is that we map that error into EREMOTEIO in the XDR
      layer, and so the NFSv4 middle-layer routines like seqid_mutating_err(),
      and nfs_increment_seqid() don't recognise it.
      
      The fix is to defer the mapping until after the middle layers have
      processed the error.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      52567b03
  5. 24 Sep, 2009 1 commit
  6. 09 Aug, 2009 2 commits
  7. 21 Jul, 2009 2 commits
    • Trond Myklebust's avatar
      NFSv4: Fix a problem whereby a buggy server can oops the kernel · d953126a
      Trond Myklebust authored
      We just had a case in which a buggy server occasionally returns the wrong
      attributes during an OPEN call. While the client does catch this sort of
      condition in nfs4_open_done(), and causes the nfs4_atomic_open() to return
      -EISDIR, the logic in nfs_atomic_lookup() is broken, since it causes a
      fallback to an ordinary lookup instead of just returning the error.
      
      When the buggy server then returns a regular file for the fallback lookup,
      the VFS allows the open, and bad things start to happen, since the open
      file doesn't have any associated NFSv4 state.
      
      The fix is firstly to return the EISDIR/ENOTDIR errors immediately, and
      secondly to ensure that we are always careful when dereferencing the
      nfs_open_context state pointer.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d953126a
    • Trond Myklebust's avatar
      NFSv4: Fix an NFSv4 mount regression · fccba804
      Trond Myklebust authored
      Commit 008f55d0 (nfs41: recover lease in
      _nfs4_lookup_root) forces the state manager to always run on mount. This is
      a bug in the case of NFSv4.0, which doesn't require us to send a
      setclientid until we want to grab file state.
      
      In any case, this is completely the wrong place to be doing state
      management. Moving that code into nfs4_init_session...
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      fccba804
  8. 12 Jul, 2009 1 commit
  9. 20 Jun, 2009 1 commit
  10. 18 Jun, 2009 1 commit
  11. 17 Jun, 2009 28 commits