Bosko Milekic wrote: > > fakepg_zone should probably be UMA_ZONE_VM. Or the vm_object lock > needs to be dropped before allocating or freeing to that zone. > > What does Alan think? (cc'd) > Perhaps. Regardless, in this case, the lock-order reversal is a false positive. What it shows is the locking of a user-level vm map, followed by vm_object #1, followed by the kmem_map. If this had proceeded to conclusion, you would have seen the locking of vm_object #2, the kmem_object. So, to witness this appears as a lock-order reversal. Unless vm_object #1 and vm_object #2 are the same, there is no possibility of deadlock. Witness is simply unable to distinguish the two vm objects because they have the same label. If they were given unique labels, witness would be overwhelmed because there are simply too many vm objects. Regards, Alan > > On Thu, Jul 31, 2003 at 04:46:06PM -0700, Lars Eggert wrote: > > Hi, > > > > with yesterday's -current: > > > > 1st 0xc6dfd094 vm object (vm object) _at_ /usr/src/sys/vm/vm_object.c:434 > > 2nd 0xc082f110 system map (system map) _at_ /usr/src/sys/vm/vm_kern.c:323 > > > > Stack backtrace: > > backtrace(c032000b,c082f110,c033362f,c033362f,c03334c6) at backtrace+0x17 > > witness_lock(c082f110,8,c03334c6,143,c082f0b0) at witness_lock+0x686 > > _mtx_lock_flags(c082f110,0,c03334c6,143,101) at _mtx_lock_flags+0xb5 > > _vm_map_lock(c082f0b0,c03334c6,143,c0374778,c03747a0) at _vm_map_lock+0x36 > > kmem_malloc(c082f0b0,1000,101,eb44db14,c02b0433) at kmem_malloc+0x3a > > page_alloc(c083a240,1000,eb44db07,101,0) at page_alloc+0x27 > > slab_zalloc(c083a240,101,c083a254,8,c0334e1e) at slab_zalloc+0xc2 > > uma_zone_slab(c083a240,101,c0334e1e,663,165) at uma_zone_slab+0xd9 > > uma_zalloc_internal(c083a240,0,101,6e7,0) at uma_zalloc_internal+0x4f > > uma_zfree_arg(c083a900,c6e31000,0,eb44dbc4,c029884d) at uma_zfree_arg+0x2a6 > > dev_pager_putfake(c6e31000,0,c0332b9e,be,c6dfd094) at dev_pager_putfake+0x35 > > dev_pager_dealloc(c6dfd094,1,c0334dcf,10c,0) at dev_pager_dealloc+0xb9 > > vm_pager_deallocate(c6dfd094,0,c0333f6c,261,1b2) at vm_pager_deallocate+0x3d > > vm_object_terminate(c6dfd094,0,c0333f6c,1b2,c6b894ec) at > > vm_object_terminate+0x1e5 > > vm_object_deallocate(c6dfd094,c082bd20,c6dfd094,c082bd20,eb44dca0) at > > vm_object_deallocate+0x35e > > vm_map_entry_delete(c6593e00,c082bd20,c033369d,897,c019f843) at > > vm_map_entry_delete+0x3c > > vm_map_delete(c6593e00,282e2000,282e3000,1000,282e2000) at > > vm_map_delete+0x3c3 > > vm_map_remove(c6593e00,282e2000,282e3000,0,c6b8a618) at vm_map_remove+0x55 > > munmap(c6ae24c0,eb44dd14,c0339293,3ee,2) at munmap+0x9e > > syscall(2f,2f,2f,f8000,1000) at syscall+0x260 > > Xint0x80_syscall() at Xint0x80_syscall+0x1d > > --- syscall (73), eip = 0x28257aa7, esp = 0xbfbffc1c, ebp = 0xbfbffc48 --- > > > > Lars > > -- > > Lars Eggert <larse_at_isi.edu> USC Information Sciences Institute > > -- > Bosko Milekic * bmilekic_at_technokratis.com * bmilekic_at_FreeBSD.org > TECHNOkRATIS Consulting Services * http://www.technokratis.com/Received on Fri Aug 01 2003 - 09:42:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:17 UTC