NFS: Treat NFS4ERR_CLID_INUSE as a fatal error
authorChuck Lever <chuck.lever@oracle.com>
Wed, 11 Jul 2012 20:30:50 +0000 (16:30 -0400)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Mon, 16 Jul 2012 19:12:16 +0000 (15:12 -0400)
commitde734831224e74fcaf8917386e33644c4243db95
treecc162230a4ae0086b5d2c4bb9e9163d18d82b826
parent46a87b8a7b939900d779042da7097bf330ab787f
NFS: Treat NFS4ERR_CLID_INUSE as a fatal error

For NFSv4 minor version 0, currently the cl_id_uniquifier allows the
Linux client to generate a unique nfs_client_id4 string whenever a
server replies with NFS4ERR_CLID_INUSE.

This implementation seems to be based on a flawed reading of RFC
3530.  NFS4ERR_CLID_INUSE actually means that the client has presented
this nfs_client_id4 string with a different principal at some time in
the past, and that lease is still in use on the server.

For a Linux client this might be rather difficult to achieve: the
authentication flavor is named right in the nfs_client_id4.id
string.  If we change flavors, we change strings automatically.

So, practically speaking, NFS4ERR_CLID_INUSE means there is some other
client using our string.  There is not much that can be done to
recover automatically.  Let's make it a permanent error.

Remove the recovery logic in nfs4_proc_setclientid(), and remove the
cl_id_uniquifier field from the nfs_client data structure.  And,
remove the authentication flavor from the nfs_client_id4 string.

Keeping the authentication flavor in the nfs_client_id4.id string
means that we could have a separate lease for each authentication
flavor used by mounts on the client.  But we want just one lease for
all the mounts on this client.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
fs/nfs/nfs4proc.c
fs/nfs/nfs4state.c
include/linux/nfs_fs_sb.h