diff mbox

understanding the need for 2 SETCLIENTIDs on the client

Message ID CAN-5tyEYLdK-reaDNrGY33jRxDuT9aSvqS_d3ERYBpSNkOUnLA@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Olga Kornievskaia April 19, 2018, 3:11 p.m. UTC 
Hi folks,

I'd like to understand the need for doing a double SETCLIENTID by the
client. Initial mount calls nfs4_init_client() which initiates
trunking discovery and calls nfs40_discover_client_trunking() which
ends up sending the SETCLIENTID to the server. However, then on the
first open, the client calls _nfs4_do_open() which calls
nfs4_client_recover_expired_lease() which checks the flags and finds
NFS4CLNT_LEASE_EXPIRED set which triggers another SETCLIENTID.

Client is created in nfs4_alloc_client() with cl_flags having
NFS4CLNT_LEASE_EXPIRED. But why doesn't a successful SETCLIENTID clear
the LEASE_EXPIRED?

If we were to clear the LEASE_EXPIRED flag (which seems like the right
thing after establishing a valid clientid), then open would find a
non-expired state.

Thoughts?

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 9796314..9ad6110 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -581,6 +581,7 @@  int nfs40_walk_client_list(struct nfs_client *new,
                        nfs4_swap_callback_idents(pos, new);
                        pos->cl_confirm = new->cl_confirm;
                        nfs_mark_client_ready(pos, NFS_CS_READY);
+                       clear_bit(NFS4CLNT_LEASE_EXPIRED, &pos->cl_state);

                        prev = NULL;
                        *result = pos;