Date: Mon, 16 Feb 2004 22:05:04 +0100 From: Maxime Henrion <mux@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Dag-Erling Smorgrav <des@FreeBSD.org> Subject: Re: cvs commit: src/sys/vm vm_kern.c Message-ID: <20040216210503.GC35475@elvis.mu.org> In-Reply-To: <28938.1076959003@critter.freebsd.dk> References: <Pine.NEB.3.96L.1040216140303.63057O-100000@fledge.watson.org> <28938.1076959003@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <Pine.NEB.3.96L.1040216140303.63057O-100000@fledge.watson.org>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040216210503.GC35475>