@@ -215,7 +215,6 @@ struct nfs_client *nfs4_alloc_client(const struct nfs_client_initdata *cl_init)
INIT_DELAYED_WORK(&clp->cl_renewd, nfs4_renew_state);
INIT_LIST_HEAD(&clp->cl_ds_clients);
rpc_init_wait_queue(&clp->cl_rpcwaitq, "NFS client");
- clp->cl_state = 1 << NFS4CLNT_LEASE_EXPIRED;
clp->cl_minorversion = cl_init->minorversion;
clp->cl_mvops = nfs_v4_minor_ops[cl_init->minorversion];
clp->cl_mig_gen = 1;
@@ -180,10 +180,6 @@ int nfs40_discover_server_trunking(struct nfs_client *clp,
/* Sustain the lease, even if it's empty. If the clientid4
* goes stale it's of no use for trunking discovery. */
nfs4_schedule_state_renewal(*result);
-
- /* If the client state need to recover, do it. */
- if (clp->cl_state)
- nfs4_schedule_state_manager(clp);
}
out:
return status;
After commit f02f3755dbd1 ("NFS4: Fix v4.0 client state corruption when mount") I have reports that sometimes all open() calls fail with -EPERM. It appears that a race between the SETCLIENTID in trunking discovery and another superflous SETCLIENTID triggered by immediately running the state manager causes the nfs_client cl_confirm value to be stored in the wrong order. It doesn't really make sense to invoke the state manager just to clear the NFS4CLNT_LEASE_EXPIRED flag. The flag has historically been used to signal that a new client still needs to perform a SETCLIENTID before creating state, but now that we have trunking discovery that flag is unnecessary. Remove the flag, remove the call to schedule the state manager from trunking discovery. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Fixes: f02f3755dbd1 ("NFS4: Fix v4.0 client state corruption when mount") Cc: stable@vger.kernel.org #v5.2 --- fs/nfs/nfs4client.c | 1 - fs/nfs/nfs4state.c | 4 ---- 2 files changed, 5 deletions(-)