delphij's Chaos

选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……

19 Jan 2004

alc commit了一个workaround但我还觉得不对头……

sys/vm/uma_int.h, rev 1.23是一个对于junsu几天前发现的问题的workaround。Alan“Thanks. I’ve committed a change making a slightly larger increase to UMA_BOOT_PAGES.”

但我怀疑这个修正的正确性。之前junsu的post中提到了一段backtrace:

panic
_mtx_lock_sleep
_mtx_lock_flags
_vm_map_lock
kmem_malloc(c0c330a0, 1000, 101, c0821ad4, c055f8c4)
page_alloc
startup_alloc
slab_zalloc
uma_zone_slab
uma_zalloc_bucket
uma_zalloc_arg
vm_map_entry_create
vm_map_insert
kmem_malloc(c0c330a0, 1000, 2, c0821c74, c055f608)

从代码上看,kmem_malloc在持有锁(vm/vm_kern.c第326行)的情况下存在潜在的递归可能(按照上面的递归路线)。毫无疑问,加大UMA_BOOT_PAGES有助于缓解问题,但我怀疑这么做的正确性——因为非常令人困惑的是,在有空间(vm_map_findspace返回0)的前提下,为什么会有vm_map_insert最终需要回过头来kmem_malloc呢?另一方面,是否应该把这里的锁换成可递归的,或者,设置标志/KASSERT找出更深层的问题?


Archived: 1 Comment

delphij | January 19, 2004 2:21 PM

Alan Cox (alc@)的最终答复:

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