Date: Thu, 1 Sep 2005 13:32:21 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-current@freebsd.org Cc: Don Lewis <truckman@freebsd.org>, rwatson@freebsd.org, dandee@volny.cz, bzeeb-lists@lists.zabbadoz.net, fli+freebsd-current@shapeshifter.se, imp@bsdimp.com Subject: Re: LOR route vr0 Message-ID: <200509011332.24342.jhb@FreeBSD.org> In-Reply-To: <200509011722.j81HMMPp021231@gw.catspoiler.org> References: <200509011722.j81HMMPp021231@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 01 September 2005 01:22 pm, Don Lewis wrote:
> 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"?
Also, are you using DEVICE_POLLING?
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509011332.24342.jhb>