From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17:18:12 2004 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 B067816A4CE for ; Fri, 10 Sep 2004 17:18:12 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5476D43D49 for ; Fri, 10 Sep 2004 17:18:12 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i8AHIBJt027879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2004 13:18:11 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i8AHI6jm060078; Fri, 10 Sep 2004 13:18:06 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16705.57806.550902.483858@grasshopper.cs.duke.edu> Date: Fri, 10 Sep 2004 13:18:06 -0400 (EDT) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: witness oddity 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: Fri, 10 Sep 2004 17:18:12 -0000 I'm trying to figure out what witness is complaining about in my (out of tree) driver code: lock order reversal 1st 0xe672baf0 MX foo mutex (MX foo mutex) @ /home/gallatin/mx/tiki/driver/freebsd/../common/mx_common.c:80 2nd 0xc1c6f878 user map (user map) @ vm/vm_map.c:2994 If I call copyout() holding one of my mutexes, it will always complain about a LOR, even if the mutex is freshly initiated: { struct mtx foo; bzero(&foo, sizeof(foo)); mtx_init(&foo, "MX foo mutex", NULL, MTX_DEF); mtx_lock(&foo); /* hacky copyout which should trigger vm_fault() */ mx_copyout(&status, 1, 4); mtx_unlock(&foo); mtx_destroy(&foo); } Is this happening because the vm_map "user map" is an sx lock? Does this imply that you can't acquire an sx lock while holding a mutex? Thanks, Drew