From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 08:15:23 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 2F91716A4CE for ; Fri, 20 Aug 2004 08:15:23 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7105643D5D for ; Fri, 20 Aug 2004 08:15:22 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i7K8869U025811 for freebsd-current@freebsd.org.checked; (8.12.8/vak/2.1) Fri, 20 Aug 2004 12:08:06 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i7K874JM025653; (8.12.8/vak/2.1) Fri, 20 Aug 2004 12:07:04 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <4125B172.9060303@cronyx.ru> Date: Fri, 20 Aug 2004 12:08:18 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Tracking down LORs 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, 20 Aug 2004 08:15:23 -0000 Robert Watson wrote: >On Fri, 20 Aug 2004, Roman Kurakin wrote: > > > >> Currently I am trying to track down a couple of LORS in my code. >>But it seems that I do not undestand smth or all things id realy so bad. >> >> > >I find it's very helpful to add lock orders to the hard-coded lock order >table in subr_witness.c. Without hard-coded entries, WITNESS will >dynamically build an order based on observed lock use. This is generally >fine, but once in a while the "wrong" order will be used before the >"right" order, so the lock order warning will print for the "right" order, >leaving less useful debugging information. The table allows the >definition of partial orders, so you can specify relationships between >subsets of mutexes of interest. WITNESS will flesh out remaining orders >through dynamic discovery. > > I'll try to go this way, since I am in dead end. rik >Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > > >> So I want to ask some questions to find out if my thoughts >>correct or wrong. >> >>1. If I am right LOR means that we have at least two mutexs. >>Lets call them a and b. If we set a, then b in first case >>and b then a in second we could get dead loop, and thus LOR. >> >>2. If I have some driver that have mutex a, and we have some >>sytem code that could call this driver with Giant (b), we would >>get LOR if driver lock a and some other part of system will >>try to lock Giant? >> >>or I am wrong? >> >>rik >> >> >> >>_______________________________________________ >>freebsd-current@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> >> > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > >