From patchwork Tue Dec 11 00:02:28 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 1860591 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 1CA433FCA5 for ; Tue, 11 Dec 2012 00:02:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751528Ab2LKACn (ORCPT ); Mon, 10 Dec 2012 19:02:43 -0500 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 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 1466EA51F5; Tue, 11 Dec 2012 01:02:41 +0100 (CET) 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> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, 29 Nov 2012 11:30:51 +1100 NeilBrown wrote: > On Wed, 28 Nov 2012 08:10:55 -0500 "J. Bruce Fields" > wrote: > > > 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. > > > > Sounds like a good idea. > > > > Just out of curiosity: how does it fail? I guess mounts just start > > failing at some point--how do people find the workaround? > > Error seems to be > > rpcsec_gss: gss_init_sec_context: (major) Miscellaneous failure - (minor) Cannot contact any KDC for requested realm > > in rpc.gssd logs. > > I guess people could read the source to find the work around .... not ideal > though. I guess we should get gssd to generate some more helpful message. > > The seem to be further problems that the customer is experiencing so I might > 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 does 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 should 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; *ind = -1; for (i=0; i