Re: LOR - 8.0-STABLE r202128
On Wednesday 13 January 2010 2:30:04 am pluknet wrote: > 2010/1/13 Gardner Bell : > > I got this lock order reversal while running a windows executable through > > wine. > > I'm guess that is a regression w.r.t S/G pager, which uses kmem_alloc/free > with vm_object locked and doesn't respect vm_map locks can sleep. > I'm curious it was back order before 5.1-R. It's more that it can call free() during the VM object's destructor. Hmm, presumably the call to sglist_free() needs to be deferred. Note that both the SG and device pagers free fake vm_page_t objects using uma_zfree() from their destructors. I guess uma_zfree() will never call kmem_free() directly? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LOR - 8.0-STABLE r202128
2010/1/13 Gardner Bell : > I got this lock order reversal while running a windows executable through > wine. I'm guess that is a regression w.r.t S/G pager, which uses kmem_alloc/free with vm_object locked and doesn't respect vm_map locks can sleep. I'm curious it was back order before 5.1-R. vm_object.c 741:/* 742: * Let the pager know object is dead. 743: */ 744:vm_pager_deallocate(object); 745:VM_OBJECT_UNLOCK(object); > > lock order reversal: > 1st 0xc5e757f8 vm object (standard object) @ > /usr/src/sys/vm/vm_object.c:482 > 2nd 0xc1c900e8 system map (system map) @ /usr/src/sys/vm/vm_map.c:2772 > KDB: stack backtrace: > db_trace_self_wrapper(c07632b0,e955d8a4,c05c7496,c05bbe7f,c076508c,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c05bbe7f,c076508c,c0923520,c48dd278,e955d8fc,...) at > kdb_backtrace+0x29 > _witness_debugger(c076508c,c1c900e8,c0765236,c48d9110,c077536f,...) at > _witness_debugger+0x1e > witness_checkorder(c1c900e8,9,c077536f,ad4,0,...) at > witness_checkorder+0x697 > _mtx_lock_flags(c1c900e8,0,c077536f,ad4,c6089000,...) at > _mtx_lock_flags+0x36 > _vm_map_lock(c1c9008c,c077536f,ad4,c66437c4,c5e757f8,...) at > _vm_map_lock+0x31 > vm_map_remove(c1c9008c,c6087000,c6089000,e955d988,c06c0417,...) at > vm_map_remove+0x2a > kmem_free(c1c9008c,c6087000,2000,e955d9a0,c06c1000,...) at kmem_free+0x30 > page_free(c6087000,2000,22,2000,e955d9b8,...) at page_free+0x46 > uma_large_free(c66437c4,c4ec09a4,c1c8c014,c5e757f8,e955d9c8,...) at > uma_large_free+0x87 > free(c6087000,c07aae1c,e955d9e0,c06bb552,c6087000,...) at free+0xb8 > sglist_free(c6087000,c598d7e0,0) at sglist_free+0x28 > sg_pager_dealloc(c5e757f8,e955da14,c06d1587,c5e757f8,0,...) at > sg_pager_dealloc+0x69 > vm_pager_deallocate(c5e757f8,0,c0775baa,2dc,0,...) at > vm_pager_deallocate+0x1a > vm_object_terminate(c5e757f8,0,c0775baa,1e2,e955da40,...) at > vm_object_terminate+0x171 > vm_object_deallocate(c5e757f8,c077536f,ad7,c5548b40,0,...) at > vm_object_deallocate+0x4ae > _vm_map_unlock(c513d740,c077536f,ad7,1,c513d740,...) at _vm_map_unlock+0x74 > vm_map_remove(c513d740,0,bfc0,0,c54e1550,...) at vm_map_remove+0x69 > vmspace_exit(c4ec0900,0,c075d9eb,12d,c07a6e7c,...) at vmspace_exit+0xbc > exit1(c4ec0900,f,c0761073,b15,1,...) at exit1+0x4f3 > sigexit(c4ec0900,f,c0761073,aa5,e955dcdc,...) at sigexit+0x9f2 > postsig(f,64,c07644d3,e8,c54e1550,...) at postsig+0x1b6 > ast(e955dd38) at ast+0x308 > doreti_ast() at doreti_ast+0x17 > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
LOR - 8.0-STABLE r202128
I got this lock order reversal while running a windows executable through wine. lock order reversal: 1st 0xc5e757f8 vm object (standard object) @ /usr/src/sys/vm/vm_object.c:482 2nd 0xc1c900e8 system map (system map) @ /usr/src/sys/vm/vm_map.c:2772 KDB: stack backtrace: db_trace_self_wrapper(c07632b0,e955d8a4,c05c7496,c05bbe7f,c076508c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05bbe7f,c076508c,c0923520,c48dd278,e955d8fc,...) at kdb_backtrace+0x29 _witness_debugger(c076508c,c1c900e8,c0765236,c48d9110,c077536f,...) at _witness_debugger+0x1e witness_checkorder(c1c900e8,9,c077536f,ad4,0,...) at witness_checkorder+0x697 _mtx_lock_flags(c1c900e8,0,c077536f,ad4,c6089000,...) at _mtx_lock_flags+0x36 _vm_map_lock(c1c9008c,c077536f,ad4,c66437c4,c5e757f8,...) at _vm_map_lock+0x31 vm_map_remove(c1c9008c,c6087000,c6089000,e955d988,c06c0417,...) at vm_map_remove+0x2a kmem_free(c1c9008c,c6087000,2000,e955d9a0,c06c1000,...) at kmem_free+0x30 page_free(c6087000,2000,22,2000,e955d9b8,...) at page_free+0x46 uma_large_free(c66437c4,c4ec09a4,c1c8c014,c5e757f8,e955d9c8,...) at uma_large_free+0x87 free(c6087000,c07aae1c,e955d9e0,c06bb552,c6087000,...) at free+0xb8 sglist_free(c6087000,c598d7e0,0) at sglist_free+0x28 sg_pager_dealloc(c5e757f8,e955da14,c06d1587,c5e757f8,0,...) at sg_pager_dealloc+0x69 vm_pager_deallocate(c5e757f8,0,c0775baa,2dc,0,...) at vm_pager_deallocate+0x1a vm_object_terminate(c5e757f8,0,c0775baa,1e2,e955da40,...) at vm_object_terminate+0x171 vm_object_deallocate(c5e757f8,c077536f,ad7,c5548b40,0,...) at vm_object_deallocate+0x4ae _vm_map_unlock(c513d740,c077536f,ad7,1,c513d740,...) at _vm_map_unlock+0x74 vm_map_remove(c513d740,0,bfc0,0,c54e1550,...) at vm_map_remove+0x69 vmspace_exit(c4ec0900,0,c075d9eb,12d,c07a6e7c,...) at vmspace_exit+0xbc exit1(c4ec0900,f,c0761073,b15,1,...) at exit1+0x4f3 sigexit(c4ec0900,f,c0761073,aa5,e955dcdc,...) at sigexit+0x9f2 postsig(f,64,c07644d3,e8,c54e1550,...) at postsig+0x1b6 ast(e955dd38) at ast+0x308 doreti_ast() at doreti_ast+0x17 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"