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. AlanReceived on Sun Jan 18 2004 - 21:14:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:38 UTC