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>
index | next in thread | previous in thread | raw e-mail
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" Silbersackhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040216200627.W4491>