This is an RFC patch because I'm not sure if this is the right way to do this... There might be a better way. Recently I've had some problems with upcalls, during mounts, hanging. The reason the hang is happening is one problem but it occurred to me the kernel should not hang forever for a daemon that may never come back. Now a couple thoughts... 1) How should the mount be failed. If ETIMEDOUT is used, the mount will be retied via the nfs4_discover_server_trunking() code. But, if the daemon is not responding why keep trying? We could error out the mount with EPIPE which cause the mount fail immediately and logging this error message NFS: nfs4_discover_server_trunking unhandled error 32. Exiting with error EIO 2) Is there a better way to do this? That timeout code looks a bit crusty :-) 3) Is the 10 sec timeout to short? Maybe we could bump it up to a 30 sec timeout? If do that I would suggest we error out the mount immediately with EPIPE. 4) Am I missing something? Steve Dickson (1): auth_rpcgss: Add a timer to the gss upcall. net/sunrpc/auth_gss/auth_gss.c | 43 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) -- 2.14.3 -- 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
