Date: Thu, 1 Sep 2005 10:22:22 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: fli+freebsd-current@shapeshifter.se Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, dandee@volny.cz, imp@bsdimp.com Subject: Re: LOR route vr0 Message-ID: <200509011722.j81HMMPp021231@gw.catspoiler.org> In-Reply-To: <4316CE7B.2090303@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 Sep, Fredrik Lindberg wrote:
> Don Lewis wrote:
>> On 27 Aug, M. Warner Losh wrote:
>>
>>>In message: <20050828025721.X43518@fledge.watson.org>
>>> Robert Watson <rwatson@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"?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509011722.j81HMMPp021231>