cvs commit: src/sys/vm vm_kern.c

[Robert Watson]

On Mon, 16 Feb 2004, Scott Long wrote:

> On Mon, 16 Feb 2004, Robert Watson wrote:
> >
> > On Mon, 16 Feb 2004, Dag-Erling Smorgrav wrote:
> >
> > >   Log:
> > >   Don't panic if we fail to satisfy an M_WAITOK request; return 0 instead.
> > >   The calling code will either handle that gracefully or cause a page fault.
> >
> > Also, this turns an easily understood and widely documented kernel panic
> > message into a page fault.  Prior to this, users could google for the
> > message and find documentation on increasing the size of the kernel
> > address space.  Now, it requires facility with the source code in order to
> > figure out what it is going on (since the page fault trace won't include
> > the memory allocation).
> 
> Agreed on all points.  I thought that there was along discussion on this
> in the last 1-2 weeks and that all of these issues were brought up. 
> Please back this out, and lets focus on getting the sematics that you
> need for procfs rather than just ruining the sematics for everything
> else. 

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.

And the origin of part of this problem is that procfs has some notions
that are hard to implement (or impossible to implement), such as:

  You can retrieve atomically snapshotted data in fairly unbounded
  ammounts.

That's not a property of our procfs implementation as much as a property
of the "procfs API".

It is useful to have some notion of the rediculous in memory allocation,
but I don't think this is the right way to enforce it.  In the general
case, we handle "reasonable" determination using small fixed-size or
tunable constants, such as maximum IOVEC size, maximum processes, maximum
mbufs, etc.  It would be very tempting to do something similar for procfs: 
"I shall allocate no more than 256k of memory for this buffer"...

This appears to change the semantics of M_NOWAIT from "Return memory if it
is available, or NULL if I need to sleep for it" into "Return memory if it
is available, or NULL if I need to sleep for it or it will never be
available".  One of the things we've been looking at doing using UMA
caching is attempting to allocate memory up front, and then if it fails,
allocating it later on demand.  Similarly, we might receive a NULL and
decide we have to release some locks and try again rather than sleep
holding the locks.  With the previous semantics, you get the panic up
front.  With the new semantics, you will panic later, but perhaps after
getting somewhere.  I'm not sure what the right answer in procfs is, but I
think this isn't it.  Maybe we need a new M_flag that says "And fail if
it's rediculous", but I'm very concerned that we just substituted memory
allocation semantics throughout the kernel and the impact it will have... 
It could be harmless, but it's also not a change to make without a lot of
hard cogitation.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research