PANIC in kmem_alloc when loading many modules

Xin LI delphij at
Sun Jan 18 20:49:43 PST 2004


> -----Original Message-----
> From: owner-freebsd-current at 
> [mailto:owner-freebsd-current at] On Behalf Of Jeff Roberson
> Sent: Friday, January 16, 2004 5:25 AM
> To: Alan Cox
> Cc: alc at; Jun Su; current at
> 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, 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

More information about the freebsd-current mailing list