mbuf panic from a kernel with a supdate=2004.06.04.02.00.00

[Brian Fundakowski Feldman]

On Thu, Jun 24, 2004 at 04:19:23PM -0600, Greg Skafte wrote:
> the last couple of days  I've gotten a panic 
> 
> panic: mb_init_pack(): Can't deal with failure yet.

This isn't a hard problem to solve, it just involves some code churn.
There are plenty of places that want the ability to fail out of an
uma_init or uma_ctor call, and so many crashes left to occur when
they hit their failure conditions without being able to return a
failure.

It's simple enough to make them return error values and have the
uma_zalloc_internal() implementation reverse its allocation and
return failure.  Do we want to leave this API in place through
all of 5.x?  We know that in practice we need to have the ability
to fail out of memory allocations even though the primary UMA backing
allocation have succeeded.

I'm certainly willing to do the work if no one else is, but I hope
that there is some agreement that this is a fundamentally necessary
thing to implement so that your crash and many others like it don't
happen.  So far, I believe all of these panic implementations are
all in kern_mbuf.c; most of them should be exactly the panic you
just ran into and any number of them when running out of memory
putting MAC labels on packets.

It's certainly possible to fix by splitting apart the init/ctor/etc.
functions more so that the caller that wants to allocate more memory
has to do so at that higher level, but that doesn't seem like the
cleanest way if developers are so wont to perform operations in
init/ctor functions that may fail.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\