On Wed, May 15, 2013 at 04:18:03PM +0000, Myklebust, Trond wrote: > On Mon, 2013-05-13 at 12:25 -0400, Chuck Lever wrote: > > Hi- > > > > Here's a stab at addressing the 15 second wait for some 3.10 sec=sys > > mounts where the client is not running rpc.gssd. > > > > After reverting the "use krb5i for SETCLIENTID" patch, I've added > > the AUTH_SYS fallback in the EACCES case in > > nfs4_discover_server_trunking(). I'm not sure whether we need to > > supplement what's there now, or replace it. > > > > "case -ENOKEY:" is added so the kernel will recognize that when gssd > > is changed to return that instead of EACCES in this case. If the > > second patch is appled to 3.7 stable and following, it might be a way > > to address the same regression in older kernels. > > > > I've been focused on another bug this week, so this has seen very > > light testing only. Looking for comments. > > I'd like to propose a different approach: we can set up rpc_pipefs files > clnt/gssd and clnt/krb5 I'm not sure what paths you mean exactly? Is "clnt" a top-level rpc-pipefs directory, or a dummy client at the level of other rpc clients (like rpc_pipefs/nfs/clnt/gssd). I'm assuming the latter--seems like it might work. Long-term, it might also be nice to add an interface to allow the kernel to determine whether gssd is running, without depending on timeouts. It could be something very trivial. --b. > as "honeypots" that rpc.gssd will connect to, > but that won't do any upcalls. When gssd connects, we set a > per-rpc_net_ns variable that tells us 'gssd' is up and running. That > variable only gets cleared if we see a timeout. > > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@xxxxxxxxxx > www.netapp.com > -- > 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 -- 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
