RFC Stop mounts hanging for user lever daemons
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest1 patch 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/1 | auth_rpcgss: Add a timer to the gss upcall.net/ | +42 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC][PATCH 0/1] Stop mounts hanging for user lever daemons
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(+)
Signature · 1 line
2.14.3