PANIC in kmem_alloc when loading many modules

[Xin LI]

> -----Original Message-----
> From: owner-freebsd-current at freebsd.org 
> [mailto:owner-freebsd-current at freebsd.org] On Behalf Of Jeff Roberson
> Sent: Friday, January 16, 2004 5:25 AM
> To: Alan Cox
> Cc: alc at freebsd.org; Jun Su; current at freebsd.org
> Subject: Re: PANIC in kmem_alloc when loading many modules
> 
> 
> I missed the beginning of this thread.  Are we loading modules 
> before the VM is bootstrapped?  If we are, we should probably 
> fix that.  If not, why do we need more boot pages?

I tend to agree Jeff's opinion. It seems that kmem_malloc has an
(inappropriate) self recursive call while it is holding the non-recursive
lock, (line 326 of vm/vm_kern.c,
http://current.freebsd.org/tour/current/kernel/S/4393.html#326). By
increasing boot pages, we may hide some (potential?) problems and make it
harder to track down.

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.

Thanks in advance!

Xin LI