On 09/27/2014 11:54 PM, Trond Myklebust wrote: > If a NFSv4.x server returns NFS4ERR_STALE_CLIENTID in response to a > CREATE_SESSION or SETCLIENTID_CONFIRM in order to tell us that it rebooted > a second time, then the client will currently take this to mean that it must > declare all locks to be stale, and hence ineligible for reboot recovery. > > RFC3530 and RFC5661 both suggest that the client should instead rely on the > server to respond to inelegible open share, lock and delegation reclaim > requests with NFS4ERR_NO_GRACE in this situation. Has our handling of NFS4ERR_NO_GRACE been tested in this situation? Anna > > Cc: stable@xxxxxxxxxxxxxxx > Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > --- > fs/nfs/nfs4state.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c > index 22fe35104c0c..26d510d11efd 100644 > --- a/fs/nfs/nfs4state.c > +++ b/fs/nfs/nfs4state.c > @@ -1761,7 +1761,6 @@ static int nfs4_handle_reclaim_lease_error(struct nfs_client *clp, int status) > break; > case -NFS4ERR_STALE_CLIENTID: > clear_bit(NFS4CLNT_LEASE_CONFIRM, &clp->cl_state); > - nfs4_state_clear_reclaim_reboot(clp); > nfs4_state_start_reclaim_reboot(clp); > break; > case -NFS4ERR_CLID_INUSE: -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
