Re: LOR route vr0

On 28 Aug, 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?

What version of subr_witness.c?  I'm not convinced that the reparenting
and rebalancing transformations in versions 1.197 and earlier won't
generate bogus lock relationships, though I'm having a hard time
thinking of a way for an inverse relationship to be "learned" and it
would seem odd that this problem would just now be showing up.  Even
hard-wired relationships can be modified on the fly by the reparenting
and rebalancing code, which *might* explain the oddness of no LORs begin
reported when the relationship is hardwired.  On the other hand I'm
certainly hoping that my changes in 1.198 aren't causing this problem.

There is some code common to both versions that provide exceptions to
the reporting of lock order reversals and the learning of certain
locking relationships, but I don't think that matters in this case.

There is some KTR code in subr_witness.c that could be used to debug
this problem, but it may not be a fine enough filter.  It might be
useful to unwire the relationship and call kdb_backtrace() from
insertchild() when the "incorrect" lock order is first learned.