From owner-cvs-src@FreeBSD.ORG  Wed Jul 30 11:55:17 2003
Return-Path: <owner-cvs-src@FreeBSD.ORG>
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 03E8037B407; Wed, 30 Jul 2003 11:55:17 -0700 (PDT)
Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 9EA8C43FD7; Wed, 30 Jul 2003 11:55:16 -0700 (PDT)
	(envelope-from bmilekic@FreeBSD.org)
Received: from repoman.freebsd.org (localhost [127.0.0.1])
	by repoman.freebsd.org (8.12.6/8.12.6) with ESMTP id h6UItF0U063472;
	Wed, 30 Jul 2003 11:55:15 -0700 (PDT)
	(envelope-from bmilekic@repoman.freebsd.org)
Received: (from bmilekic@localhost)
	by repoman.freebsd.org (8.12.6/8.12.6/Submit) id h6UItFgg063471;
	Wed, 30 Jul 2003 11:55:15 -0700 (PDT)
Message-Id: <200307301855.h6UItFgg063471@repoman.freebsd.org>
From: Bosko Milekic <bmilekic@FreeBSD.org>
Date: Wed, 30 Jul 2003 11:55:15 -0700 (PDT)
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-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jul 2003 18:55:17 -0000

bmilekic    2003/07/30 11:55:15 PDT

  FreeBSD src repository

  Modified files:
    sys/vm               uma_core.c 
  Log:
  Plug a race and a leak in UMA.
  
  1) The race has to do with zone destruction.  From the zone destructor we
     would lock the zone, set the working set size to 0, then unlock the zone,
     drain it, and then free the structure.  Within the window following the
     working-set-size set to 0 and unlocking of the zone and the point where
     in zone_drain we re-acquire the zone lock, the uma timer routine could
     have fired off and changed the working set size to something non-zero,
     thereby potentially preventing us from completely freeing slabs before
     destroying the zone (and thus leaking them).
  
  2) The leak has to do with zone destruction as well.  When destroying a
     zone we would take care to free all the buckets cached in the zone, but
     although we would drain the pcpu cache buckets, we would not free them.
     This resulted in leaking a couple of bucket structures (512 bytes each)
     per cpu on SMP during zone destruction.
  
  While I'm here, also silence GCC warnings by turning uma_slab_alloc()
  from inline to real function.  It's too big to be an inline.
  
  Reviewed by: JeffR
  
  Revision  Changes    Path
  1.69      +29 -13    src/sys/vm/uma_core.c