From owner-cvs-src@FreeBSD.ORG Mon Feb 16 13:05:09 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 3EA2F16A4CE; Mon, 16 Feb 2004 13:05:09 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3928643D1D; Mon, 16 Feb 2004 13:05:09 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 11A145C79A; Mon, 16 Feb 2004 13:05:04 -0800 (PST) Date: Mon, 16 Feb 2004 22:05:04 +0100 From: Maxime Henrion To: Poul-Henning Kamp Message-ID: <20040216210503.GC35475@elvis.mu.org> References: <28938.1076959003@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28938.1076959003@critter.freebsd.dk> User-Agent: Mutt/1.4.1i cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: Scott Long cc: cvs-all@FreeBSD.org cc: Robert Watson 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 21:05:09 -0000 Poul-Henning Kamp wrote: > In message , Robe > rt Watson writes: > > >It seems like it all comes down to the perfectly reasonable desire to be > >able to represent the following request: > > > > Userspace wants me to allocate some memory. I don't know how large > > rediculous is, but I don't want to panic when I ask for something > > rediculous and instead get a failure I can report. > > Sounds like we need to add a new flag: M_TELL_ME_IF_I_AM_STUPID I suggested an M_SAFE patch for malloc(9) to Dag and did a patch for it already. The semantics are "return NULL and don't panic if I'm asking for too much". I find this useful because there are cases where we are asked to do something by an userland program, via a syscall or something else, that will require us to allocate X bytes of memory. In those cases, we generally make the code enforce artificial limits, to prevent the kernel form panic'ing. It's practically impossible to have meaningful limits, so we end up having yet another compile-time kernel option. There is also some code that totally ignores it, probably because the author didn't know about the panic() in kmem_malloc(). I find it very convenient to have a flag to tell malloc() to try as hard as it can to allocate the memory without crashing on us. I suspect this could allow us to remove a fair number of kernel compile-time options. The patch can be found at http://www.mu.org/~mux/patches/malloc.patch. Cheers, Maxime