LOR route vr0
jhb at FreeBSD.org
Mon Aug 29 18:36:01 GMT 2005
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
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-current