From owner-cvs-src@FreeBSD.ORG Sun Jul 4 16:14:13 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 419FE16A4CE; Sun, 4 Jul 2004 16:14:13 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AE5043D1F; Sun, 4 Jul 2004 16:14:13 +0000 (GMT) (envelope-from bmilekic@FreeBSD.org) Received: from freefall.freebsd.org (bmilekic@localhost [127.0.0.1]) i64GEDXn082896; Sun, 4 Jul 2004 16:14:13 GMT (envelope-from bmilekic@freefall.freebsd.org) Received: (from bmilekic@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i64GEDvq082895; Sun, 4 Jul 2004 16:14:13 GMT (envelope-from bmilekic) Date: Sun, 4 Jul 2004 16:14:13 +0000 From: Bosko Milekic To: Brian Feldman Message-ID: <20040704161413.GA82599@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i 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 16:14:13 -0000 This is unfair. I told you both in public and in private that I didn't think this approach of segragating this behavior to mbuf allocations was the right approach and even suggested what the right approach should have been. You asked me to review a change that further segragated this behavior to mbuf allocations but then committed the change 5 minutes later without giving me an opportunity to reply. What I've done is made the sysctl-introduction change myself and committed it instead of this. In the future I hope that you'll learn to be more patient and less righteous when ordering others not to commit something before going through the SO. -Bosko The commit log: green 2004-07-04 15:59:25 UTC FreeBSD src repository Modified files: sys/vm uma_core.c Log: Reextend the M_WAITOK-disabling-hack to all three of the mbuf-related zones, and do it by direct comparison of uma_zone_t instead of strcmp. The mbuf subsystem used to provide M_TRYWAIT/M_DONTWAIT semantics, but this is mostly no longer the case. M_WAITOK has taken over the spot M_TRYWAIT used to have, and for mbuf things, still may return NULL if the code path is incorrectly holding a mutex going into mbuf allocation functions. The M_WAITOK/M_NOWAIT semantics are absolute; though it may deadlock the system to try to malloc or uma_zalloc something with a mutex held and M_WAITOK specified, it is absolutely required to not return NULL and will result in instability and/or security breaches otherwise. There is still room to add the WITNESS_WARN() to all cases so that we are notified of the possibility of deadlocks, but it cannot change the value of the "badness" variable and allow allocation to actually fail except for the specialized cases which used to be M_TRYWAIT. Revision Changes Path 1.99 +4 -2 src/sys/vm/uma_core.c