Date: Tue, 17 Feb 2004 09:10:49 +0100 From: Maxime Henrion <mux@freebsd.org> To: Mike Silbersack <silby@silby.com> Cc: Dag-Erling Smorgrav <des@FreeBSD.org> Subject: Re: cvs commit: src/sys/vm vm_kern.c Message-ID: <20040217081049.GG35475@elvis.mu.org> In-Reply-To: <20040216200627.W4491@odysseus.silby.com> 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> <20040216200627.W4491@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > > > <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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040217081049.GG35475>