PANIC in kmem_alloc when loading many modules

Alan Cox alc at
Sun Jan 18 22:14:07 PST 2004

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.


More information about the freebsd-current mailing list