PANIC in kmem_alloc when loading many modules
delphij at frontfree.net
Sun Jan 18 20:49:43 PST 2004
> -----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,
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!
More information about the freebsd-current