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 <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Mon Aug 29 2005 - 16:36:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:42 UTC