From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from cantor2.suse.de ([195.135.220.15]:50225 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751156Ab2LKACm (ORCPT ); Mon, 10 Dec 2012 19:02:42 -0500 Date: Tue, 11 Dec 2012 11:02:28 +1100 From: NeilBrown To: "J. Bruce Fields" Cc: Steve Dickson , linux-nfs@vger.kernel.org Subject: Re: [PATCH 3/3] gssd: base the size of the fd array on the RLIMIT_NOFILE limit. Message-ID: <20121211110228.0159fc4f@notabene.brown> In-Reply-To: <20121129113051.046bc658@notabene.brown> References: <20121128010939.2475.13123.stgit@notabene.brown> <20121128011123.2475.13691.stgit@notabene.brown> <20121128131054.GB11651@fieldses.org> <20121129113051.046bc658@notabene.brown> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/MD7KluzxDeoyOGifaJJE67c"; protocol="application/pgp-signature" Sender: linux-nfs-owner@vger.kernel.org List-ID: --Sig_/MD7KluzxDeoyOGifaJJE67c Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 29 Nov 2012 11:30:51 +1100 NeilBrown wrote: > On Wed, 28 Nov 2012 08:10:55 -0500 "J. Bruce Fields" > wrote: >=20 > > On Wed, Nov 28, 2012 at 12:11:23PM +1100, Neil Brown wrote: > > > We have previously raised the size of the 'pollarray' once (32 -> 256) > > > and I have had another request to make it bigger. > > > Rather than changing the hard-coded value, make it depend on > > > RLIMIT_NOFILE. This is an upper limit on the size of the array > > > that can be passed to poll() anyway. > >=20 > > Sounds like a good idea. > >=20 > > Just out of curiosity: how does it fail? I guess mounts just start > > failing at some point--how do people find the workaround? >=20 > Error seems to be >=20 > rpcsec_gss: gss_init_sec_context: (major) Miscellaneous failure - (minor)= Cannot contact any KDC for requested realm >=20 > in rpc.gssd logs. >=20 > I guess people could read the source to find the work around .... not ide= al > though. I guess we should get gssd to generate some more helpful message. >=20 > The seem to be further problems that the customer is experiencing so I mi= ght > wait until they are completely resolved to ensure I have complete > understanding before I propose a further patch. The "further problem" was that krb5 libraries use select() in a way that do= es not support file descriptors higher than 1024. This is fixed in the latest krb5 so that is no longer an issue. I've been thinking about your question, and about how best to deliver a fix to customers, and I really think it should all "just work". i.e. the array that gssd should be sized dynamically and RLIMIT_NOFILE shou= ld be increased as needed. I haven't tested this, but what do people think? I don't have a problem changing the rlim_cur limit like this, but I wonder if it is OK to dynamically set rlim_max. Thoughts? NeilBrown diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c index d01ba2f..3576a6f 100644 --- a/utils/gssd/gssd_proc.c +++ b/utils/gssd/gssd_proc.c @@ -389,18 +389,36 @@ static int get_poll_index(int *ind) { unsigned int i; + struct pollfd *new_pollarray; + struct rlimit rlim; =20 *ind =3D -1; for (i=3D0; i