Date: Sun, 28 Aug 2005 05:20:13 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz Subject: Re: LOR route vr0 Message-ID: <20050828051917.W52467@fledge.watson.org> In-Reply-To: <20050827.220303.130848154.imp@bsdimp.com> References: <20050827184153.A24510@fledge.watson.org> <20050827.124941.14976142.imp@bsdimp.com> <20050828025721.X43518@fledge.watson.org> <20050827.220303.130848154.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050828051917.W52467>