Re: LOR route vr0

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_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"?

Also, are you using DEVICE_POLLING?

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org