Return-Path: linux-nfs-owner@vger.kernel.org Received: from aserp1040.oracle.com ([141.146.126.69]:50628 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753484Ab3KLRMy convert rfc822-to-8bit (ORCPT ); Tue, 12 Nov 2013 12:12:54 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [PATCH 0/2] sunrpc: more reliable detection of running gssd From: Chuck Lever In-Reply-To: <1384275379.4779.8.camel@leira.trondhjem.org> Date: Tue, 12 Nov 2013 12:12:48 -0500 Cc: Jeff Layton , "linux-nfs@vger.kernel.org" , "steved@redhat.com" Message-Id: References: <1384261225-28559-1-git-send-email-jlayton@redhat.com> <20131112110831.72234c64@tlielax.poochiereds.net> <1384275379.4779.8.camel@leira.trondhjem.org> To: "Myklebust, Trond" Sender: linux-nfs-owner@vger.kernel.org List-ID: On Nov 12, 2013, at 11:56 AM, "Myklebust, Trond" wrote: > On Tue, 2013-11-12 at 11:15 -0500, Chuck Lever wrote: >> On Nov 12, 2013, at 11:08 AM, Jeff Layton wrote: >> >>> On Tue, 12 Nov 2013 11:02:42 -0500 >>> Chuck Lever wrote: >>> >>>> >>>> On Nov 12, 2013, at 8:00 AM, Jeff Layton wrote: >>>> >>> What's the module loading solution? >> >> Load auth_rpcgss.ko only when rpc.gssd has been started. See the "[PATCH] Adding the nfs4_secure_mounts bool" thread... If auth_rpcgss.ko is not loaded, the kernel won't ever try to do an upcall. >> >> Then, systemd can be used to restart rpc.gssd if it crashes, maybe? Just a thought. > > You can trivially defeat that by compiling the gss code into the kernel. My solution is a workaround. It works for distributions that do not compile auth_rpcgss into the kernel, since they are the ones who provide an appropriate init script architecture. But it does not require a kernel code change, and it applies to every distribution I'm aware of. Since distributions typically do not use built-in GSS support, I'm not too concerned about whoever might be left over. And I never said that we shouldn't continue to mitigate the upcall timeout. Note that Jeff's solution didn't entirely eliminate the problem either. With either or both of these solutions in place, we are better off than we were before. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com