diff options
| author |   NeilBrown <neilb@suse.com> | 2017-12-13 09:57:09 +1100 |
|---|---|---|
| committer |   Trond Myklebust <trond.myklebust@primarydata.com> | 2018-01-14 23:06:29 -0500 |
| commit | dce2630c7da73b0634686bca557cc8945cc450c8 (patch) | |
| tree | 43ce15a2e404c830f30e071cd998d6ab8d618c27 /tools/perf/scripts/python/export-to-postgresql.py | |
| parent | nfs: remove dead code from nfs_encode_fh() (diff) | |
| download | wireguard-linux-dce2630c7da73b0634686bca557cc8945cc450c8.tar.xz wireguard-linux-dce2630c7da73b0634686bca557cc8945cc450c8.zip | |
NFSv4: always set NFS_LOCK_LOST when a lock is lost.
There are 2 comments in the NFSv4 code which suggest that
SIGLOST should possibly be sent to a process. In these
cases a lock has been lost.
The current practice is to set NFS_LOCK_LOST so that
read/write returns EIO when a lock is lost.
So change these comments to code when sets NFS_LOCK_LOST.
One case is when lock recovery after apparent server restart
fails with NFS4ERR_DENIED, NFS4ERR_RECLAIM_BAD, or
NFS4ERRO_RECLAIM_CONFLICT. The other case is when a lock
attempt as part of lease recovery fails with NFS4ERR_DENIED.
In an ideal world, these should not happen. However I have
a packet trace showing an NFSv4.1 session getting
NFS4ERR_BADSESSION after an extended network parition. The
NFSv4.1 client treats this like server reboot until/unless
it get NFS4ERR_NO_GRACE, in which case it switches over to
"nograce" recovery mode. In this network trace, the client
attempts to recover a lock and the server (incorrectly)
reports NFS4ERR_DENIED rather than NFS4ERR_NO_GRACE. This
leads to the ineffective comment and the client then
continues to write using the OPEN stateid.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions