LOR route vr0

[John Baldwin]

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.org