On Wed, 2013-05-15 at 12:22 -0400, Chuck Lever wrote: > On May 15, 2013, at 12:18 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> 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 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. > > Note my solution is a short term gap filler. Bruce and Jeff seem to want something that can fix current kernels without requiring user space changes, and I need something that will allow sec=krb5 mounts to work without a client keytab on kernels since 3.7. > > I see your proposal as a long term fix, and not something that we can expect to apply without deploying gssd support at the same time. How does it require gssd modifications? The whole point is that it requires kernel-only changes, and only minor changes at that... -- 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
