From owner-cvs-all@FreeBSD.ORG Tue Feb 17 00:10:50 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 052A316A4CE; Tue, 17 Feb 2004 00:10:50 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id F20A643D3F; Tue, 17 Feb 2004 00:10:49 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id EBEAE5C78F; Tue, 17 Feb 2004 00:10:49 -0800 (PST) Date: Tue, 17 Feb 2004 09:10:49 +0100 From: Maxime Henrion To: Mike Silbersack Message-ID: <20040217081049.GG35475@elvis.mu.org> References: <28938.1076959003@critter.freebsd.dk> <20040216210503.GC35475@elvis.mu.org> <6.0.1.1.1.20040217013021.03a47a30@imap.sfu.ca> <20040216200627.W4491@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040216200627.W4491@odysseus.silby.com> User-Agent: Mutt/1.4.1i cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: Scott Long cc: Colin Percival cc: Poul-Henning Kamp cc: Robert Watson cc: cvs-all@FreeBSD.org cc: Dag-Erling Smorgrav Subject: Re: cvs commit: src/sys/vm vm_kern.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, 17 Feb 2004 08:10:50 -0000 Mike Silbersack wrote: > > On Tue, 17 Feb 2004, Colin Percival wrote: > > > At 21:05 16/02/2004, Maxime Henrion wrote: > > >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. > > > > > > Is this really good enough? When I was routinely running my system out > > of kernel memory by using a large malloc backed md(4), the panic never > > came from a failed allocation in the md code; rather, md would use up all > > the available memory, and then some other kernel call (which needed only > > some small amount of memory) would panic. > > From a security point of view, I can't see how there's any alternative > > to using a user-allocated buffer for such requests. > > > > > > Colin Percival > > The M_SAFE and M_NOWAIT flags could be set to leave a 10% memory buffer > that only M_WAITOK callers would eat into. This would (hopefully) help to > avoid panicing the system, while still maintaining the desired semantic > for M_WAITOK callers. > > Er, wait, maybe M_WAITOK callers should block at that boundary, and > M_NOWAIT should succeed... hrm. > > Either way, something should be done, the current state of affairs isn't > all that perfect. Wait a minute... I just realized the code does quite different things than what I thought it does. I was under the impression that the kmem_malloc() panic only occured when someone asked for a size bigger than the total size of kmem_map, and it actually happens whenever there isn't enough room in kmem_map to satisfy the request. That changes the deal quite a bit. This means the M_WAITOK flag doesn't do what it's supposed to do, because it should sleep until the request can be satisfied. The panic() (and so, the M_SAFE flag) still makes sense when we are asked for a size > kmem_map.size though. This problem appears to be more complicated than I expected. I'm starting to think that we can't really enforce M_WAITOK semantics and that we should maybe think about going the M_TRYWAIT way, like for mbuf allocations. I'd be interested to know the opinion of our VM experts... Cheers, Maxime