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. \,,,,,,,,,,,,,,,,,,,,,,\Received on Thu Jun 24 2004 - 22:24:40 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:58 UTC