Date: Fri, 20 Aug 2004 13:02:26 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-current@FreeBSD.org Cc: Roman Kurakin <rik@cronyx.ru> Subject: Re: Tracking down LORs Message-ID: <200408201302.26421.jhb@FreeBSD.org> In-Reply-To: <4125B172.9060303@cronyx.ru> References: <Pine.NEB.3.96L.1040820001041.20697B-100000@fledge.watson.org> <4125B172.9060303@cronyx.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 20 August 2004 04:08 am, Roman Kurakin wrote: > 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. Note that some lock orders as also inferred via transitivity. For example, let's say you have three locks a, b, and c. One thread locks a then b, so witness saves that order. A second thread locks b then c, so witness saves that order. If a third thread tries to lock c then a, an LOR will result. This is similar to how > is transitive, i.e. if a > b and b > c, then a > c. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408201302.26421.jhb>