From owner-freebsd-current Tue Feb 21 03:52:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA04132 for current-outgoing; Tue, 21 Feb 1995 03:52:35 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id DAA04101 for ; Tue, 21 Feb 1995 03:52:27 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id DAA07072; Tue, 21 Feb 1995 03:52:04 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id DAA00893; Tue, 21 Feb 1995 03:52:03 -0800 Message-Id: <199502211152.DAA00893@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: Bruce Evans cc: jhs@regent.e-technik.tu-muenchen.de, current@FreeBSD.org Subject: Re: Possible kern.maxproc fatal bug In-reply-to: Your message of "Tue, 21 Feb 95 19:18:14 +1100." <199502210818.TAA10312@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 21 Feb 1995 03:51:57 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >>>As last line in my /etc/rc.local I used to have >>> sysctl -w kern.maxproc=300 >>>An innocent >>> cd /usr/ports ; make -i >>>would then always crash the system (even when compiled as normal user, >>>& with everything in ports having been changed to owner jhs (thus no suid 0 >>>stuff lurking in /usr/ports)). > >> Probably because the proc table is not dynamically sized. Basically, you >>can't change maxproc - it probably should not by managed by sysctl. > >But it is dynamically sized. I can't see any problems that would cause >a panic. Not completely. The problem is that the upages must be mapped in kernel memory. There used to be a problem with allocation failures caused by map fragmentation...until I created a seperate map to contain the upages (kernel stack and 'u' info). The size of this map is calculated at startup time and effectively sets the upper maximum on the total number of processes to whatever "maxproc" was at startup time. Other than creating a "balance set", there really isn't any way of working around this problem other than making the map much large than maxproc (and thus allow maxproc to grow much larger). Perhaps making the map accomodate 2 or 3 times maxproc might be a compromise. -DG