LOR route vr0
Don Lewis
truckman at FreeBSD.org
Thu Sep 1 17:22:40 GMT 2005
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) @ /usr/src/sys/netinet/tcp_input.c:742
> 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172
>
> lock order reversal
> 1st 0xc1e06bb8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1269
> 2nd 0xc1b74018 fxp0 (network driver) @/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"?
More information about the freebsd-current
mailing list