From owner-cvs-src@FreeBSD.ORG Mon Feb 16 14:07:00 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37EC816A4CE; Mon, 16 Feb 2004 14:07:00 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B163143D1D; Mon, 16 Feb 2004 14:06:59 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i1GM6wLE020230; Tue, 17 Feb 2004 09:06:58 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1GM6u0I015506; Tue, 17 Feb 2004 09:06:57 +1100 Date: Tue, 17 Feb 2004 09:06:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson In-Reply-To: Message-ID: <20040217084935.T15065@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Dag-Erling Smorgrav Subject: Re: cvs commit: src/sys/vm vm_kern.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 22:07:00 -0000 On Mon, 16 Feb 2004, Robert Watson wrote: > On Mon, 16 Feb 2004, Dag-Erling Smorgrav wrote: I think you mean: "On Mon, 16 Feb 2004, someone using Dag-Erling Smorgrav's terminal wrote:" > > > Log: > > Don't panic if we fail to satisfy an M_WAITOK request; return 0 instead. > > The calling code will either handle that gracefully or cause a page fault. This is just a bug. > Also, this turns an easily understood and widely documented kernel panic > message into a page fault. Prior to this, users could google for the > message and find documentation on increasing the size of the kernel > address space. Now, it requires facility with the source code in order to > figure out what it is going on (since the page fault trace won't include > the memory allocation). I disagree that a panic is better than a page fault. Page faults are much easier to debug. They are restartable using a debugger in all cases, and can be made to not repeat endlessly in some cases. But they should not occur after M_WAITOK malloc's, since the main reason for existence of M_WAITOK is to avoid having to handle malloc() returning NULL. Actually, a panic still occurs for the main consumer (malloc(9)) if INVARIANTS is configured, and the collateral change to malloc()'s documentation is wrong in this case. The panic message is just even less useful than the old one: old panic message: panic("kmem_malloc(%ld): kmem_map too small: %ld total allocated", (long)size, (long)map->size); new panic message (if the allocation is done by malloc()): if (flags & M_WAITOK) KASSERT(va != NULL, ("malloc(M_WAITOK) returned NULL")); BTW, the old panic message has lots of printf format errors (sizes may be truncated by casting them down and the casts don't even preserve unsignedness) and style bugs (a long line and wrong continuation indent). Bruce