UDP LOR with the latest RELENG_7

Jeremy Chadwick koitsu at FreeBSD.org
Sun Oct 12 12:12:35 PDT 2008


On Sun, Oct 12, 2008 at 10:08:30PM +0300, Vlad GALU wrote:
> On Sun, Oct 12, 2008 at 1:40 PM, Robert Watson <rwatson at freebsd.org> wrote:
> >
> > On Fri, 10 Oct 2008, Robert Watson wrote:
> >
> >> On Fri, 10 Oct 2008, Jeremy Chadwick wrote:
> >>
> >>>>  I'll see whether the system still locks up or not though..
> >>>
> >>> Okay, I'm bringing rwatson@ into the thread since this is specific to
> >>> UDP.
> >>
> >> I've now fixed the bug leading to the lock order reversal; I'd be
> >> interested in knowing if it also corrects the stability issue.  This was
> >> r183753 in svn; I'm not sure it's hit CVS/cvsup yet but should do in a few
> >> minutes.
> >
> > Dear Vlad:
> >
> > Could you confirm that with udp_usrreq.c:1.218.2.7 (or newer), the problem
> > has gone away?  CVS log excerpt below.
> 
>  Hello Robert & all,
>  Yes, the LOR seems to have gone away now, even with
> net.inet.udp.soreceive_dgram_enabled=1.
>  However, I started seeing another one:
> 
> -- cut here --
> lock order reversal:
>  1st 0xffffffff805a62a0 pf task mtx (pf task mtx) @
> /usr/src/sys/contrib/pf/net/
>                                      pf.c:6773
>  2nd 0xffffff00011e3cf0 radix node head (radix node head) @
> /usr/src/sys/net/rou
>                              te.c:293
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> witness_checkorder() at witness_checkorder+0x565
> _mtx_lock_flags() at _mtx_lock_flags+0x2f
> rtalloc1_fib() at rtalloc1_fib+0x85
> rtalloc_ign_fib() at rtalloc_ign_fib+0xaa
> pf_calc_mss() at pf_calc_mss+0x89
> pf_test_tcp() at pf_test_tcp+0xce2
> pf_test() at pf_test+0xcdb
> pf_check_in() at pf_check_in+0x2b
> pfil_run_hooks() at pfil_run_hooks+0xac
> ip_input() at ip_input+0x2dd
> ether_demux() at ether_demux+0x1b4
> ether_input() at ether_input+0x1c6
> bge_intr() at bge_intr+0x3d0
> ithread_loop() at ithread_loop+0xe9
> fork_exit() at fork_exit+0x110
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffffffa044dd30, rbp = 0 ---
> -- and here --
> 
>    This one looks somewhat familiar (from the top of my head), but
> it's probably a subject for another thread :)

This looks like a LOR in the pf(4) code.  Am I that correct?  If so,
this should go to the freebsd-pf list.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |



More information about the freebsd-stable mailing list