diff options
| author | NeilBrown <neilb@suse.com> | 2017-12-13 01:57:09 +0300 |
|---|---|---|
| committer | Trond Myklebust <trond.myklebust@primarydata.com> | 2018-01-15 07:06:29 +0300 |
| commit | dce2630c7da73b0634686bca557cc8945cc450c8 (patch) | |
| tree | 43ce15a2e404c830f30e071cd998d6ab8d618c27 /mm/truncate.c | |
| parent | aaa1500894655427f1b964d1f31dbbd20baa80ab (diff) | |
| download | linux-dce2630c7da73b0634686bca557cc8945cc450c8.tar.xz | |
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 'mm/truncate.c')
0 files changed, 0 insertions, 0 deletions