Re: fxp(4) patch

Randy Bush wrote:
> ok, i got a crash and managed to call doadump successfully
> 
> db> trace
> Tracing pid 28 tid 100029 td 0xc1329cf0
> kdb_enter(c0657700,c069e180,c065a89d,d0066b4c,100) at kdb_enter+0x30
> panic(c065a89d,c1b28b00,0,0,c16f3884) at panic+0xd5
> sbdrop_locked(c16f3884,a2,7ccf5787,34,c16c0c5c) at sbdrop_locked+0x46
> sbdrop(c16f3884,a2,c256f568,c,0) at sbdrop+0x5f
> tcp_input(c256f500,14,c149f800,1,0) at tcp_input+0xe9e
> ip_input(c256f500,1,3960c3a8,8a8ccdb5,c06ba1f4) at ip_input+0x570
> netisr_processqueue(c06a3ef8,1ff2f3,7868bbda,246,0) at netisr_processqueue+0xe9
> swi_net(0,0,0,0,0) at swi_net+0x11f
> ithread_loop(c1311300,d0066d48,15,55ff44fd,23232323) at ithread_loop+0x1a8
> fork_exit(c04db120,c1311300,d0066d48) at fork_exit+0x7f
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xd0066d7c, ebp = 0 ---
> 
> and then the kgdb backtrace
> 
> #0  doadump () at pcpu.h:164
> #1  0xc0443c95 in db_fncall (dummy1=1016, dummy2=0, dummy3=1016, 
>     dummy4=0xd0066974 "") at /usr/src/sys/ddb/db_command.c:531
> #2  0xc0443a22 in db_command (last_cmdp=0xc0697dc4, cmd_table=0x0, 
>     aux_cmd_tablep=0xc066a298, aux_cmd_tablep_end=0xc066a29c)
>     at /usr/src/sys/ddb/db_command.c:349
> #3  0xc0443b35 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
> #4  0xc0445cb5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
> #5  0xc0511177 in kdb_trap (type=0, code=0, tf=0xd0066acc)
>     at /usr/src/sys/kern/subr_kdb.c:421
> #6  0xc062ed48 in trap (frame=
>       {tf_fs = -1067122664, tf_es = 16, tf_ds = -804913136, tf_edi = 1, tf_esi = -1067079523, tf_ebp = -804885740, tf_isp = -804885768, tf_ebx = -804885684, tf_edx = 0, tf_ecx = -1061072896, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1068429712, tf_cs = 8, tf_eflags = 662, tf_esp = -1067086374, tf_ss = -1067092224}) at /usr/src/sys/i386/i386/trap.c:573
> #7  0xc061f76a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #8  0xc0650018 in ?? ()
> #9  0x00000010 in ?? ()
> #10 0xd0060010 in ?? ()
> #11 0x00000001 in ?? ()
> #12 0xc065a89d in ?? ()
> #13 0xd0066b14 in ?? ()
> #14 0xd0066af8 in ?? ()
> #15 0xd0066b4c in ?? ()
> #16 0x00000000 in ?? ()
> #17 0xc0c15000 in ?? ()
> #18 0x00000012 in ?? ()
> #19 0x00000003 in ?? ()
> #20 0x00000000 in ?? ()
> #21 0xc0510e70 in kdb_enter (msg=0x0) at cpufunc.h:60
> #22 0xc04f2c95 in panic (fmt=0xc065a89d "sbdrop")
>     at /usr/src/sys/kern/kern_shutdown.c:538
> #23 0xc053c936 in sbdrop_locked (sb=0xc16f3884, len=8)
>     at /usr/src/sys/kern/uipc_socket2.c:1149
> #24 0xc053cb2f in sbdrop (sb=0xc16f3884, len=0)
>     at /usr/src/sys/kern/uipc_socket2.c:1200
> #25 0xc059264e in tcp_input (m=0xc256f500, off0=20)
>     at /usr/src/sys/netinet/tcp_input.c:1196
> #26 0xc058a210 in ip_input (m=0xc256f500)
>     at /usr/src/sys/netinet/ip_input.c:776
> #27 0xc05792e9 in netisr_processqueue (ni=0xc06a3ef8)
>     at /usr/src/sys/net/netisr.c:235
> #28 0xc057954f in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:348
> #29 0xc04db2c8 in ithread_loop (arg=0xc1311300)
>     at /usr/src/sys/kern/kern_intr.c:546
> #30 0xc04da1ff in fork_exit (callout=0xc04db120 <ithread_loop>, arg=0x0, 
>     frame=0x0) at /usr/src/sys/kern/kern_fork.c:790
> #31 0xc061f7cc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208

That's interesting but this doesn't seem to be related to fxp(4) at all.
The stacktrace show that sbdrop_locked() calls panic() here:

       next = (m = sb->sb_mb) ? m->m_nextpkt : 0;
       while (len > 0) {
                if (m == 0) {
                        if (next == 0)
                                panic("sbdrop");

Meaning that sb->sb_mb was NULL when tcp_input() called sbdrop_locked().
This may be the result of a race condition somewhere but I can't tell.
Someone with free time and more knowledge of the TCP/IP stack could
probably know what's going on.

Cheers,
Maxime