NeilBrown 608848f0a6 NFSv4: always set NFS_LOCK_LOST when a lock is lost.
[ Upstream commit dce2630c7da73b0634686bca557cc8945cc450c8 ]

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>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-30 07:48:52 +02:00
..
2017-12-20 10:04:56 +01:00
2017-08-06 19:19:42 -07:00
2017-11-30 08:37:20 +00:00
2015-11-13 20:34:33 -05:00
2015-11-23 21:11:08 -05:00
2015-11-10 12:07:22 -08:00
2017-06-14 13:16:24 +02:00
2015-11-16 23:54:45 -08:00
2018-05-16 10:06:51 +02:00
2015-11-16 23:54:45 -08:00
2017-06-14 13:16:24 +02:00
2018-02-16 20:09:43 +01:00
2017-06-14 13:16:24 +02:00