From owner-freebsd-current@FreeBSD.ORG  Sun Jan 18 22:14:07 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id A539616A4CE; Sun, 18 Jan 2004 22:14:07 -0800 (PST)
Received: from cs.rice.edu (cs.rice.edu [128.42.1.30])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 96EF643D46; Sun, 18 Jan 2004 22:14:05 -0800 (PST)
	(envelope-from alc@cs.rice.edu)
Received: from localhost (localhost [127.0.0.1])
	by cs.rice.edu (Postfix) with ESMTP
	id 1F3224A9BB; Mon, 19 Jan 2004 00:14:05 -0600 (CST)
Received: from cs.rice.edu ([127.0.0.1])
 by localhost (cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 00608-01-53; Mon, 19 Jan 2004 00:14:03 -0600 (CST)
Received: by cs.rice.edu (Postfix, from userid 19572)
	id 8A9AB4A9B2; Mon, 19 Jan 2004 00:14:03 -0600 (CST)
Date: Mon, 19 Jan 2004 00:14:03 -0600
From: Alan Cox <alc@cs.rice.edu>
To: Xin LI <delphij@frontfree.net>
Message-ID: <20040119061403.GB7891@cs.rice.edu>
References: <20040115162427.L36463-100000@mail.chesapeake.net>
	<20040119044936.44D0D114C9@beastie.frontfree.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040119044936.44D0D114C9@beastie.frontfree.net>
User-Agent: Mutt/1.3.28i
X-Virus-Scanned: by amavis-20030616-p5 at rice.edu
cc: alc@freebsd.org
cc: 'Jeff Roberson' <jroberson@chesapeake.net>
cc: 'Jun Su' <junsu@m-net.arbornet.org>
cc: current@freebsd.org
Subject: Re: PANIC in kmem_alloc when loading many modules
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jan 2004 06:14:07 -0000

On Mon, Jan 19, 2004 at 12:49:45PM +0800, Xin LI wrote:
>  ...
> A brief reading of the code told me that when vm_map_findspace return 0, in
> other words, we found a space, then the lock would be kept held by
> kmem_alloc, but at line 346,  vm_map_insert would have a chance to call
> kmem_malloc through the following call path: 
> 
> kmem_malloc(346) -> vm_map_insert(843) -> vm_map_entry_create(555) ->
> uma_zalloc(234) -> uma_zalloc_arg(1459) -> uma_zalloc_bucket(1619) ->
> uma_zone_slab(1529) -> slab_zalloc(750, through zone->uz_allocf function
> pointer) -> startup_alloc(821) -> page_alloc(842) -> kmem_malloc (PANIC Here
> because recursively lock on non-recursive lock)
> 
> Maybe we should re-implement page_alloc to prevent kmem_malloc call? I am
> not familiar with the VM code so that's just my 2 cents.

No.  Once vm_init2() is performed, UMA uses obj_alloc() rather than
page_alloc() to implement vm_map_entry_create() for kernel map entries.
This is simply a case of exhausting UMA_BOOT_PAGES before initialization
is complete.

Alan