I'm working on an issue in an older kernel where we see occasional panics when trying to refresh credentials. Here's the bug in case anyone is interested: https://bugzilla.redhat.com/show_bug.cgi?id=572870 ...I think I understand the problem well enough now. The problem is pretty complex, but the issue is that some operations are done using credentials from a stateowner associated with a nfs_client, but using the rpc_clnt in nfs_server->client. The two can have different authtypes if there are a mix of mounts with different authtypes to the same server. This problem seems to have been fixed in mainline with the introduction of the auth_generic code. It leaves me wondering though...what exactly is the reason for having two rpc_clients per NFS mount? To clarify, I'm talking about these two, which seem to be somewhat redundant: nfs_server->client nfs_server->nfs_client->cl_rpcclient On mount, the nfs4_set_client calls nfs_get_client to search the list of nfs_client structs until it finds one that matches the address, port, etc of the NFS server. If one isn't found, the kernel creates one using whatever authtype was requested for the mount. Later, nfs_init_server_rpcclient looks at the rpc_clnt in the nfs_client and copies it. If the auth pseudoflavor doesn't match however, it creates a new rpc_auth for it. What exactly is the point of having two rpc_clnt's? Why not just get always use nfs_client->cl_rpcclient instead of nfs_server->client and simply have nfs_get_client filter by authtype? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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