Date: Mon, 19 Jan 2004 00:14:03 -0600 From: Alan Cox <alc@cs.rice.edu> To: Xin LI <delphij@frontfree.net> Cc: current@freebsd.org Subject: Re: PANIC in kmem_alloc when loading many modules Message-ID: <20040119061403.GB7891@cs.rice.edu> In-Reply-To: <20040119044936.44D0D114C9@beastie.frontfree.net> References: <20040115162427.L36463-100000@mail.chesapeake.net> <20040119044936.44D0D114C9@beastie.frontfree.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040119061403.GB7891>