[Bug 231064] data abort in in_pcbremlbgrouphash() on ThunderX

Fri Aug 31 19:45:43 UTC 2018

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231064

            Bug ID: 231064
           Summary: data abort in in_pcbremlbgrouphash() on ThunderX
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: markj at FreeBSD.org

I'm testing -ALPHA3 on a packet.net ThunderX.  When I boot GENERIC-NODEBUG, the
kernel panics right about the time it gets to the login prompt:

(kgdb) bt
#0  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:366
#1  0xffff00000018f520 in db_dump (dummy=-281474967580032, dummy2=false,
dummy3=-1, dummy4=0xffff00014d3cdb4c "") at /usr/src/sys/ddb/db_command.c:574
#2  0xffff00000018f298 in db_command (last_cmdp=0xffff000001018258
<db_last_command>, cmd_table=0x0, dopager=1) at
/usr/src/sys/ddb/db_command.c:481
#3  0xffff00000018edc8 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:534
#4  0xffff0000001951e0 in db_trap (type=37, code=0) at
/usr/src/sys/ddb/db_main.c:252
#5  0xffff0000007050c0 in kdb_trap (type=37, code=0, tf=0xffff00014d3ce1e0) at
/usr/src/sys/kern/subr_kdb.c:693
#6  0xffff000000c8bec8 in data_abort (td=0xfffffd006112f000,
frame=0xffff00014d3ce1e0, esr=2516582404, far=16777259, lower=0)
    at /usr/src/sys/arm64/arm64/trap.c:261
#7  0xffff000000c8b858 in do_el1h_sync (td=0xfffffd006112f000,
frame=0xffff00014d3ce1e0) at /usr/src/sys/arm64/arm64/trap.c:341
#8  <signal handler called>
#9  0xffff0000008b5280 in in_pcbremlbgrouphash (inp=0xfffffd00e975a9b0) at
/usr/src/sys/netinet/in_pcb.c:414
#10 0xffff0000008b504c in in_pcbdrop (inp=0xfffffd00e975a9b0) at
/usr/src/sys/netinet/in_pcb.c:1687
#11 0xffff0000009d4eb4 in tcp_close (tp=0xfffffd00e975d3d0) at
/usr/src/sys/netinet/tcp_subr.c:1991
#12 0xffff0000009c13c0 in tcp_do_segment (m=0xfffffd0049dfe100,
th=0xfffffd0049e6b0a8, so=0xfffffd007bbfd000, tp=0xfffffd00e975d3d0,
drop_hdrlen=52, 
    tlen=31, iptos=0 '\000') at /usr/src/sys/netinet/tcp_input.c:2306
#13 0xffff0000009be02c in tcp_input (mp=0xffff00014d3ceff8,
offp=0xffff00014d3cefd0, proto=6) at /usr/src/sys/netinet/tcp_input.c:1392
#14 0xffff0000008c203c in ip_input (m=0x0) at
/usr/src/sys/netinet/ip_input.c:827
#15 0xffff000000877330 in netisr_dispatch_src (proto=1, source=0,
m=0xfffffd0049dfe100) at /usr/src/sys/net/netisr.c:1122
#16 0xffff000000877ac4 in netisr_dispatch (proto=1, m=0xfffffd0049dfe100) at
/usr/src/sys/net/netisr.c:1213
#17 0xffff0000008468a0 in ether_demux (ifp=0xfffffd0049a02000,
m=0xfffffd0049dfe100) at /usr/src/sys/net/if_ethersubr.c:874
#18 0xffff000000848fbc in ether_input_internal (ifp=0xfffffd0049a02000,
m=0xfffffd0049dfe100) at /usr/src/sys/net/if_ethersubr.c:662
#19 0xffff0000008487e0 in ether_nh_input (m=0xfffffd0049dfe100) at
/usr/src/sys/net/if_ethersubr.c:692
#20 0xffff000000877330 in netisr_dispatch_src (proto=5, source=0,
m=0xfffffd0049dfe100) at /usr/src/sys/net/netisr.c:1122
#21 0xffff000000877ac4 in netisr_dispatch (proto=5, m=0xfffffd0049dfe100) at
/usr/src/sys/net/netisr.c:1213
#22 0xffff000000847100 in ether_input (ifp=0xfffffd00498e4800,
m=0xfffffd0049dfe100) at /usr/src/sys/net/if_ethersubr.c:782
#23 0xffff0000009c5d6c in tcp_lro_flush (lc=0xffff000149546788,
le=0xfffffd000ae25bf0) at /usr/src/sys/netinet/tcp_lro.c:397
#24 0xffff0000009c6c78 in tcp_lro_rx2 (lc=0xffff000149546788,
m=0xfffffd0049dfe000, csum=56586, use_hash=1) at
/usr/src/sys/netinet/tcp_lro.c:785
#25 0xffff0000009c7414 in tcp_lro_rx (lc=0xffff000149546788,
m=0xfffffd0049dfe000, csum=0) at /usr/src/sys/netinet/tcp_lro.c:952
#26 0xffff000000ce1b80 in nicvf_rcv_pkt_handler (nic=0xfffffd00330d1000,
cq=0xffff000149547480, cqe_rx=0xffff00016f402800, cqe_type=2)
    at /usr/src/sys/dev/vnic/nicvf_queues.c:678
#27 0xffff000000ce181c in nicvf_cq_intr_handler (nic=0xfffffd00330d1000,
cq_idx=4 '\004') at /usr/src/sys/dev/vnic/nicvf_queues.c:774
#28 0xffff000000ce1424 in nicvf_cmp_task (arg=0xffff000149547480, pending=1) at
/usr/src/sys/dev/vnic/nicvf_queues.c:887
#29 0xffff00000072817c in taskqueue_run_locked (queue=0xfffffd004b261800) at
/usr/src/sys/kern/subr_taskqueue.c:465
#30 0xffff00000072a304 in taskqueue_thread_loop (arg=0xffff000149547500) at
/usr/src/sys/kern/subr_taskqueue.c:757
#31 0xffff00000061d680 in fork_exit (callout=0xffff00000072a1a4
<taskqueue_thread_loop>, arg=0xffff000149547500, frame=0xffff00014d3cf960)
    at /usr/src/sys/kern/kern_fork.c:1057
#32 <signal handler called>

Interestingly, the panic does not occur under GENERIC.  It does occur if I
recompile GENERIC-NODEBUG with -O0, so I'm able to get a usable kernel dump. 
Clearly "grp" is a bogus pointer, but it's not clear where it comes from:

(kgdb) frame 9
#9  0xffff0000008b5280 in in_pcbremlbgrouphash (inp=0xfffffd00e975a9b0) at
/usr/src/sys/netinet/in_pcb.c:414                                               
414                     for (i = 0; i < grp->il_inpcnt; ++i) {
(kgdb) info local
pcbinfo = 0xffff0000e9851820
hdr = 0xffff000148a3bbb0
grp = 0xffffff
i = 0
(kgdb) p *hdr
$1 = {lh_first = 0x0}

-- 
You are receiving this mail because:
You are the assignee for the bug.