From owner-freebsd-current@FreeBSD.ORG Fri Jun 25 00:24:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C475416A4CE; Fri, 25 Jun 2004 00:24:39 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i5P0OdDn008593; Thu, 24 Jun 2004 20:24:39 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i5P0OcME008592; Thu, 24 Jun 2004 20:24:38 -0400 (EDT) (envelope-from green) Date: Thu, 24 Jun 2004 20:24:38 -0400 From: Brian Fundakowski Feldman To: Greg Skafte Message-ID: <20040625002438.GE1112@green.homeunix.org> References: <20040624221923.GA29852@trollkarl.skafte.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040624221923.GA29852@trollkarl.skafte.org> User-Agent: Mutt/1.5.6i cc: jeff@FreeBSD.org cc: Freebsd-current@FreeBSD.org cc: bmilekic@FreeBSD.org Subject: Re: mbuf panic from a kernel with a supdate=2004.06.04.02.00.00 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 00:24:40 -0000 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@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\