(Apologies for the resend to people on the cc list. I forgot to
cc linux-nfs@vger...)
v3:
- get rid of unneeded argument to init_client nfs op
- move gssd_running check into rpc_pipe.c to eliminate dependency on
auth_gss.ko
v2:
- change name of toplevel pipefs dir from "dummy" to "gssd" (per
Trond's suggestion)
- when gssd isn't running, don't bother to upcall (per Neil B.'s
suggestion)
- fix lifecycle of rpc_pipe data. Previously it would have leaked
after umount. With this set, it's created and destroyed along with
the netns, and just attached to the pipe inode on mount/unmount
of rpc_pipefs.
- patch has been added to skip attempting setclientid with krb5i
if gssd isn't running. This avoids the "AUTH_GSS upcall timed out"
message when gssd isn't running and you mount with sec=sys. It also
shortens the delay when gssd isn't up.
The original cover letter from the v1 posting follows. Note that this
set does address the warnings about the AUTH_GSS upcall timing out.
-------------------------[snip]-----------------------------
We've gotten a lot of complaints recently about the 15s delay when
doing a sec=sys mount without gssd running.
A large part of the problem is that the kernel isn't able to reliably
detect when rpc.gssd is running. What we currently have is a
gssd_running flag that is initially set to 1. When an upcall times out,
that gets set to 0, and subsequent upcalls get a much shorter timeout
(1/4s instead of 15s). It's reset back to '1' when a pipe is reopened.
The approach of using a flag like this is pretty inadequate. First, it
doesn't eliminate the long delay on the initial upcall attempt. Also,
if gssd spontaneously dies, then the flag will still be set to 1 until
the next upcall attempt times out. Finally, it currently requires that
the pipe be reopened in order to reset the flag back to true.
This patchset replaces that flag with a more reliable mechanism for
detecting when gssd is running. When rpc_pipefs is mounted, it creates a
new "dummy" pipe that gssd will naturally find and hold open. We'll
never send an upcall down this pipe, and writing to it always fails.
But, since we can detect when something is holding it open, we can use
that to determine whether gssd is running.
The current patch just uses this mechanism to replace the gssd_running
flag with this new mechanism. This shortens the long delay when mounting
without gssd running, but does not silence these warnings:
RPC: AUTH_GSS upcall timed out.
Please check user daemon is running.
I'm willing to add a patch to do that, but I'm a little unclear on the
best way to do so. Those messages are generated by the auth_gss code. We
probably do want to print them if someone mounted with sec=krb5, but
suppress them when mounting with sec=sys.
Do we need to somehow pass down that intent to auth_gss? Another idea
would be to call gssd_running() from the nfs mount code and use that to
determine whether to try and use krb5 at all...
Discuss!
*** BLURB HERE ***
clone of "master"
Jeff Layton (3):
sunrpc: create a new dummy pipe for gssd to hold open
sunrpc: replace sunrpc_net->gssd_running flag with a more reliable
check
nfs: check if gssd is running before attempting to use krb5i auth in
SETCLIENTID call
fs/nfs/nfs4client.c | 6 +-
include/linux/sunrpc/rpc_pipe_fs.h | 17 +++++-
net/sunrpc/auth_gss/auth_gss.c | 10 ++--
net/sunrpc/netns.h | 3 +-
net/sunrpc/rpc_pipe.c | 109 ++++++++++++++++++++++++++++++++++---
net/sunrpc/sunrpc_syms.c | 8 ++-
6 files changed, 136 insertions(+), 17 deletions(-)
--
1.8.3.1
--
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
