From owner-cvs-src@FreeBSD.ORG Sun Jul 4 05:34:40 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 41A8216A4CE; Sun, 4 Jul 2004 05:34:40 +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 i645Yd4X004170; Sun, 4 Jul 2004 01:34: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 i645YdwG004169; Sun, 4 Jul 2004 01:34:39 -0400 (EDT) (envelope-from green) Date: Sun, 4 Jul 2004 01:34:38 -0400 From: Brian Fundakowski Feldman To: Bosko Milekic Message-ID: <20040704053438.GB964@green.homeunix.org> References: <20040704042027.GA94373@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040704042027.GA94373@freefall.freebsd.org> User-Agent: Mutt/1.5.6i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm uma_core.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2004 05:34:40 -0000 On Sun, Jul 04, 2004 at 04:20:27AM +0000, Bosko Milekic wrote: > > This change is bogus. It checks uz_name against "Mbuf" but mbuma also > defines a "Packet" zone. > > Even if that were fixed, I would personally prefer a backout. The > original intent of this [temporary] piece of code is to help detect > potential deadlocks and make sure that they don't happen, as they are > generally tougher to debug than traps on NULL pointer dereferences. > The fact that without WITNESS M_WAITOK is actually overriden by > M_NOWAIT behavior, although conservative, ensures that deadlock due > to, say, locks being held while sleeping. > > The need for the temporary code is still significant because we still > have code paths that could potentially lead to deadlock here. I'd > rather proactively, albeit conservatively, avoid that deadlock, knowing > that the situation where even M_NOWAIT will return NULL should not > occur unless I have heavy/unexpected load anyway. > > With that said, I would agree to you adding a way to have badness on > 0 by default, possibly by making it a debug boot-time tunable, or > better, rw-sysctl. Backing this out is inappropriate -- malloc(WAITOK) may never fail. Please further correct behavior for mbufs, but don't break malloc/zalloc for everyone as it was when EVER returning NULL for WAITOK. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\