From owner-cvs-all@FreeBSD.ORG Tue Mar 23 02:52:59 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6681016A4CE; Tue, 23 Mar 2004 02:52:59 -0800 (PST) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id A69F843D54; Tue, 23 Mar 2004 02:52:58 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (211.26.204.134) by smtp01.syd.iprimus.net.au (7.0.024) id 402BA92700E0162A; Tue, 23 Mar 2004 21:52:56 +1100 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 6235A41BD; Tue, 23 Mar 2004 21:53:10 +1100 (EST) Date: Tue, 23 Mar 2004 21:53:10 +1100 From: Tim Robbins To: Pawel Jakub Dawidek Message-ID: <20040323105310.GA14855@cat.robbins.dropbear.id.au> References: <200403230837.i2N8bZe4025918@repoman.freebsd.org> <20040323103300.GK8930@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323103300.GK8930@darkness.comp.waw.pl> User-Agent: Mutt/1.4.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2004 10:52:59 -0000 On Tue, Mar 23, 2004 at 11:33:00AM +0100, Pawel Jakub Dawidek wrote: > On Tue, Mar 23, 2004 at 12:37:35AM -0800, Tim J. Robbins wrote: > +> tjr 2004/03/23 00:37:34 PST > +> > +> FreeBSD src repository > +> > +> Modified files: > +> sys/vm vm_map.c > +> Log: > +> Do not copy vm_exitingcnt to the new vmspace in vmspace_exec(). Copying > +> it led to impossibly high values in the new vmspace, causing it to never > +> drop to 0 and be freed. > > How serious it is? Do you planning to MFC it to RELENG_4 with peter@'s > patch of course? A user can cause the kernel to allocate an unbounded amount of wired memory, causing the machine to panic or stop responding. It's been observed to happen under real workloads; that is, the circumstances are not so contrived that the bug could only be caused by a malicious user. I don't have any immediate plans to MFC it (I don't have any 4.x systems right now), but peter@ or ps@ may want to after letting it settle for a while in -current. Tim