Date: Tue, 24 Jun 2003 14:55:33 -0500 From: "Alan L. Cox" <alc@imimic.com> To: Kris Kennaway <kris@obsecurity.org> Cc: current@FreeBSD.org Subject: Re: LOR in VM (with backtrace) Message-ID: <3EF8ACB5.C8379525@imimic.com> References: <20030624004308.GA17534@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > CURRENT dated June 19; > > lock order reversal > 1st 0xc45788ac vm object (vm object) @ /a/asami/portbuild/i386/src-client/sys/vm/vm_object.c:1506 > 2nd 0xc082f110 system map (system map) @ /a/asami/portbuild/i386/src-client/sys/vm/vm_kern.c:328 > > Debugger(c03f450d,c082f110,c043190e,c043190e,c043178f) at Debugger+0x54 > witness_lock(c082f110,8,c043178f,148,d8ca79f8) at witness_lock+0x6ac > _mtx_lock_flags(c082f110,0,c043178f,148,c4496850) at _mtx_lock_flags+0xb1 > _vm_map_lock(c082f0b0,c043178f,148,c025dc34,246) at _vm_map_lock+0x36 > kmem_malloc(c082f0b0,1000,101,d8ca7a8c,c0390425) at kmem_malloc+0x65 > page_alloc(c083a240,1000,d8ca7a7f,101,c0457e2c) at page_alloc+0x27 > slab_zalloc(c083a240,101,c04332aa,66e,c414e5c4) at slab_zalloc+0x155 > uma_zone_slab(c083a240,101,c04332aa,66e,0) at uma_zone_slab+0xd8 > uma_zalloc_internal(c083a240,0,101,6ee,0) at uma_zalloc_internal+0x55 > uma_zfree_arg(c414e5a0,d7a86000,0,1,0) at uma_zfree_arg+0x2cc > swp_pager_meta_free(c45788ac,1d,0,1,0) at swp_pager_meta_free+0x1b2 > swap_pager_freespace(c45788ac,1d,0,1,0) at swap_pager_freespace+0x57 > vm_object_backing_scan(c4bec5c8,4,c0432299,5f7,c0432299) at vm_object_backing_scan+0x28a > vm_object_collapse(c4bec5c8,0,c0432299,1ef,c45a0ec4) at vm_object_collapse+0x11a > vm_object_deallocate(c4fab940,c5093ce4,c4fab940,c5093ce4,d8ca7c60) at vm_object_deallocate+0x28e > vm_map_entry_delete(c1506100,c5093ce4,c043197c,86d,c041ada4) at vm_map_entry_delete+0x3b > vm_map_delete(c1506100,0,bfc00000,c1506100,c4123f00) at vm_map_delete+0x413 > vm_map_remove(c1506100,0,bfc00000,11d,65) at vm_map_remove+0x55 > exit1(c4496850,0,c041a26b,65,d8ca7d40) at exit1+0x63d > sys_exit(c4496850,d8ca7d10,c0437c26,3fd,1) at sys_exit+0x41 > syscall(2f,2f,2f,0,ffffffff) at syscall+0x26e > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2829e9ff, esp = 0xbfbfde3c, ebp = 0xbfbfde58 --- > Thanks for letting me know. This is another false positive: Witness can't distinguish the lock on the object being destroyed from the lock on the object used by UMA because their labels are the same. They will never, however, be the same object. So, deadlock isn't a risk. I will probably disable witness checking on the "system map" mutexes (or at least the kmem_map's mutex) shortly so that folks don't become conditioned to ignoring these. Regards, Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EF8ACB5.C8379525>