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 WatsonReceived on Sun Aug 28 2005 - 02:20:17 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:42 UTC