Date: Mon, 16 Feb 2004 20:08:47 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Colin Percival <colin.percival@wadham.ox.ac.uk> Cc: Dag-Erling Smorgrav <des@FreeBSD.org> Subject: Re: cvs commit: src/sys/vm vm_kern.c Message-ID: <20040216200627.W4491@odysseus.silby.com> In-Reply-To: <6.0.1.1.1.20040217013021.03a47a30@imap.sfu.ca> References: <Pine.NEB.3.96L.1040216140303.63057O-100000@fledge.watson.org> <28938.1076959003@critter.freebsd.dk> <20040216210503.GC35475@elvis.mu.org> <6.0.1.1.1.20040217013021.03a47a30@imap.sfu.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > <hat="kernel newbie"> > 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. > </hat> > > 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. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040216200627.W4491>