[PATCH v3 0/3] sunrpc/nfs: more reliable detection of running gssd

* [PATCH v3 0/3] sunrpc/nfs: more reliable detection of running gssd
@ 2013-11-13 21:52 Jeff Layton
  2013-11-13 21:52 ` [PATCH v3 1/3] sunrpc: create a new dummy pipe for gssd to hold open Jeff Layton
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Jeff Layton @ 2013-11-13 21:52 UTC (permalink / raw)
  To: trond.myklebust; +Cc: chuck.lever, neilb, steved, linux-nfs

(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

^ permalink raw reply	[flat|nested] 5+ messages in thread