From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:18:24 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 7F95116A4CE for ; Fri, 10 Sep 2004 18:18:24 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F3043D2F for ; Fri, 10 Sep 2004 18:18:24 +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 i8AIINJt007854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2004 14:18:23 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i8AIII6R060166; Fri, 10 Sep 2004 14:18:18 -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.61418.553065.584034@grasshopper.cs.duke.edu> Date: Fri, 10 Sep 2004 14:18:18 -0400 (EDT) To: John-Mark Gurney In-Reply-To: <20040910172515.GU72089@funkthat.com> References: <16705.57806.550902.483858@grasshopper.cs.duke.edu> <20040910172515.GU72089@funkthat.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-current@freebsd.org Subject: Re: 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 18:18:24 -0000 John-Mark Gurney writes: > Andrew Gallatin wrote this message on Fri, Sep 10, 2004 at 13:18 -0400: > > If I call copyout() holding one of my mutexes, it will always complain > > about a LOR, even if the mutex is freshly initiated: > > Calling copyout while holding a mutex is not allowed... If the page > isn't in memory, it could take many seconds for the page to be swapped > back in during which time your mutex will continue to be held. Thanks.. but that's not really what I asked. I want to know how witness detects a particular just-created mutex as being in a deadlock with the vm map lock. Again, is it because the vm lock is an sx lock? Is there an implicit rule that you can't take an sx lock while holding a mutex (just like you can't take Giant, or sleep?) Or is it some ordering principal that I don't understand. DRew