From owner-freebsd-current@FreeBSD.ORG Tue Jun 24 12:55:37 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1259737B42B for ; Tue, 24 Jun 2003 12:55:37 -0700 (PDT) Received: from mail26a.sbc-webhosting.com (mail26a.sbc-webhosting.com [216.173.237.164]) by mx1.FreeBSD.org (Postfix) with SMTP id 10B9D43FDF for ; Tue, 24 Jun 2003 12:55:36 -0700 (PDT) (envelope-from alc@imimic.com) Received: from www.imimic.com (64.143.12.21)2-0602324532; Tue, 24 Jun 2003 15:55:32 -0400 (EDT) Sender: alc@FreeBSD.ORG Message-ID: <3EF8ACB5.C8379525@imimic.com> Date: Tue, 24 Jun 2003 14:55:33 -0500 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway References: <20030624004308.GA17534@rot13.obsecurity.org> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 cc: alc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: LOR in VM (with backtrace) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2003 19:55:37 -0000 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