Re: LOR route vr0

On  1 Sep, Fredrik Lindberg wrote:
> Don Lewis wrote:
>> On 27 Aug, M. Warner Losh wrote:
>> 
>>>In message: <20050828025721.X43518_at_fledge.watson.org>
>>>            Robert Watson <rwatson_at_FreeBSD.org> writes:
>>>: 
>>>: On Sat, 27 Aug 2005, M. Warner Losh wrote:
>>>: 
>>>: > : You need to add an entry to subr_witness.c creating a graph edge between
>>>: > : the softc lock and the routing lock.  An example of an entry in
>>>: > : subr_witness.c:
>>>: > :
>>>: > :          /*
>>>: > :           * TCP/IP
>>>: > :           */
>>>: > :          { "tcp", &lock_class_mtx_sleep },
>>>: > :          { "tcpinp", &lock_class_mtx_sleep },
>>>: > :          { "so_snd", &lock_class_mtx_sleep },
>>>: > :          { NULL, NULL },
>>>: > :
>>>: > : Note that sets of ordered entries are terminated with a double-null.  This
>>>: > : declares that locks of type "tcp" preceed "tcpinp" which preceed
>>>: > : "so_snd".
>>>: >
>>>: > So you have to have locks of type tcp BEFORE you take out tcpinp type 
>>>: > locks?
>>>: 
>>>: 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).
>> 
>> 
>> Just as a datapoint, I've got fxp interfaces on all my machines running
>> -CURRENT and I'm not seeing the problem here.
>> 
> 
> I'm seeing both the rentry and the tcpinp LORs on my fxp interface
> on a machine running a few days old -current (Aug 25).
> 
> lock order reversal
> 1st 0xc1e30d38 inp (tcpinp) _at_ /usr/src/sys/netinet/tcp_input.c:742
> 2nd 0xc1b74018 fxp0 (network driver) _at_/usr/src/sys/dev/fxp/if_fxp.c:1172
> 
> lock order reversal
> 1st 0xc1e06bb8 rtentry (rtentry) _at_ /usr/src/sys/net/route.c:1269
> 2nd 0xc1b74018 fxp0 (network driver) _at_/usr/src/sys/dev/fxp/if_fxp.c:1172
> 
> As for their backtraces they are almost identical to the
> once already posted.

Are you using any applications that use multicast?  Can you break into
DDB and capture the output of "show witness"?