From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 18:36:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 B310916A423; Mon, 29 Aug 2005 18:36:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9258143D53; Mon, 29 Aug 2005 18:36:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 29 Aug 2005 14:51:03 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 14:13:23 -0400 User-Agent: KMail/1.8 References: <20050827184153.A24510@fledge.watson.org> <20050827.220303.130848154.imp@bsdimp.com> <20050828051917.W52467@fledge.watson.org> In-Reply-To: <20050828051917.W52467@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508291413.25426.jhb@FreeBSD.org> Cc: bzeeb-lists@lists.zabbadoz.net, Robert Watson , dandee@volny.cz, "M. Warner Losh" Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 29 Aug 2005 18:36:01 -0000 On Sunday 28 August 2005 12:20 am, Robert Watson wrote: > On Sat, 27 Aug 2005, M. Warner Losh wrote: > > : Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, > > : and 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and > > : then tcp, the above settings should cause WITNESS to generate a lock > > : order warning. Likewise, both tcp and tcpinp preceed so_snd, so if you > > : acquire a protocol lock after a socket lock, it will get unhappy. > > : WITNESS handles transitive relationships, so it gets connected up to > > : the rest of the lock graph, explicit and implicit, so indirect > > : violations of orders are fully handled. > > > > OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked > > version of ed, not in tree GIANT locked ed). > > > > I've made the following changes, and the LORs go away (except for one, > > which was unrelated). I further don't get the first place where they > > locks happen that caused the original LORs, so I'm mightly confused. > > Hmm. I've seen another identical report recently -- that when a lock > order is put into WITNESS, reversals against it are not reported. I > wonder if we've got a witness bug on our hands? Note that in this case the problem shows up because of a series of transitive lock orders. It would be useful to see the graph from show witness before you add the hard-coded entries to see why it thinks rtentry comes after MTX_NETWORK_LOCK. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org