From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 13:11:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C461065674 for ; Mon, 23 Mar 2009 13:11:44 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id 3E7B48FC13 for ; Mon, 23 Mar 2009 13:11:43 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 24690 invoked from network); 23 Mar 2009 12:45:03 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 23 Mar 2009 12:45:03 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id C15B11031D; Mon, 23 Mar 2009 12:45:02 +0000 (UTC) Date: Mon, 23 Mar 2009 12:45:02 +0000 From: ttw+bsd@cobbled.net To: Boris Kochergin Message-ID: <20090323124502.GA8686@holyman.cobbled.net> Mail-Followup-To: Boris Kochergin , freebsd-hackers@freebsd.org References: <49C6F4F4.5030609@acm.poly.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C6F4F4.5030609@acm.poly.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:11:45 -0000 On 22.03-22:33, Boris Kochergin wrote: > Ahoy. I got bitten by this today--a system I administer for someone had > users in more than 16 groups, so I had to bump the value, recompile the > kernel, and reboot. It seems desirable to (at the very least) make this > a read-only tunable that can be set using /boot/loader.conf, so as to > avoid source modification and kernel recompilation. I had a look around, > and noticed that NGROUPS_MAX is used to construct static arrays in a > couple of locations ("ibcs2_gid_t iset[NGROUPS_MAX];"). It seems that > malloc(9)/MALLOC(9) can be used to allocate memory for the array > instead, and panic() (or something) can be called if the allocation > fails, no? Is that about the gist of it? If I'm not overlooking > something major, I'd like to take a stab at it. i've sumbitted a patch for this to hackers@' list but actually bumping the groups limit is more work. i'm pretty far on with it but am unsure wwhen it'll be completed. if anyone wishes a copy of the patches or current working patch then i'd be happy to post it. note that bumping NGROUPS_MAX will do little in itself.