From owner-cvs-all@FreeBSD.ORG  Wed Jun 23 22:01:12 2004
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 72FB216A4CE; Wed, 23 Jun 2004 22:01:12 +0000 (GMT)
Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 6D54243D39; Wed, 23 Jun 2004 22:01:12 +0000 (GMT)
	(envelope-from bmilekic@FreeBSD.org)
Received: from repoman.freebsd.org (localhost [127.0.0.1])
	by repoman.freebsd.org (8.12.11/8.12.11) with ESMTP id i5NLx3A0056491;
	Wed, 23 Jun 2004 21:59:03 GMT
	(envelope-from bmilekic@repoman.freebsd.org)
Received: (from bmilekic@localhost)
	by repoman.freebsd.org (8.12.11/8.12.11/Submit) id i5NLx3It056490;
	Wed, 23 Jun 2004 21:59:03 GMT
	(envelope-from bmilekic)
Message-Id: <200406232159.i5NLx3It056490@repoman.freebsd.org>
From: Bosko Milekic <bmilekic@FreeBSD.org>
Date: Wed, 23 Jun 2004 21:59:03 +0000 (UTC)
To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org,
	cvs-all@FreeBSD.org
X-FreeBSD-CVS-Branch: HEAD
Subject: cvs commit: src/sys/vm uma_core.c
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2004 22:01:12 -0000

bmilekic    2004-06-23 21:59:03 UTC

  FreeBSD src repository

  Modified files:
    sys/vm               uma_core.c 
  Log:
  Make uma_mtx MTX_RECURSE.  Here's why:
  
  The general UMA lock is a recursion-allowed lock because
  there is a code path where, while we're still configured
  to use startup_alloc() for backend page allocations, we
  may end up in uma_reclaim() which calls zone_foreach(zone_drain),
  which grabs uma_mtx, only to later call into startup_alloc()
  because while freeing we needed to allocate a bucket.  Since
  startup_alloc() also takes uma_mtx, we need to be able to
  recurse on it.
  
  This exact explanation also added as comment above mtx_init().
  
  Trace showing recursion reported by: Peter Holm <peter-at-holm.cc>
  
  Revision  Changes    Path
  1.97      +11 -1     src/sys/vm/uma_core.c