cvs commit: src/sys/vm vm_kern.c

[Maxime Henrion]

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