Re: ng_snd_item: Panic?

From: Larry Rosenman <ler_at_lerctr.org>
Date: Mon, 24 Jun 2019 15:10:40 -0500
On 06/24/2019 3:01 pm, Andrey V. Elsukov wrote:
> 24.06.2019 21:32, Larry Rosenman пишет:
>> Got 2 of these today, and I have cores....
>> Ideas?
>> r349200.
>> 
>> Unread portion of the kernel message buffer:
>> panic: ng_snd_item: 42 != 1414
>> cpuid = 10
>> time = 1561382494
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> 0xfffffe012628d400
>> vpanic() at vpanic+0x19d/frame 0xfffffe012628d450
>> panic() at panic+0x43/frame 0xfffffe012628d4b0
>> ng_snd_item() at ng_snd_item+0x477/frame 0xfffffe012628d4f0
>> ng_ether_output() at ng_ether_output+0x5e/frame 0xfffffe012628d520
>> ether_output() at ether_output+0x473/frame 0xfffffe012628d5c0
>> arpintr() at arpintr+0xfe3/frame 0xfffffe012628d780
>> netisr_dispatch_src() at netisr_dispatch_src+0x89/frame 
>> 0xfffffe012628d7f0
>> ether_demux() at ether_demux+0x137/frame 0xfffffe012628d820
>> ng_ether_rcv_upper() at ng_ether_rcv_upper+0x95/frame 
>> 0xfffffe012628d840
>> ng_apply_item() at ng_apply_item+0xf1/frame 0xfffffe012628d8c0
>> ng_snd_item() at ng_snd_item+0x2ab/frame 0xfffffe012628d900
>> ng_apply_item() at ng_apply_item+0xf1/frame 0xfffffe012628d980
>> ng_snd_item() at ng_snd_item+0x2ab/frame 0xfffffe012628d9c0
>> ng_ether_input() at ng_ether_input+0x4c/frame 0xfffffe012628d9f0
>> ether_nh_input() at ether_nh_input+0x2cd/frame 0xfffffe012628da40
>> netisr_dispatch_src() at netisr_dispatch_src+0x89/frame 
>> 0xfffffe012628dab0
>> ether_input() at ether_input+0x48/frame 0xfffffe012628dad0
>> bce_intr() at bce_intr+0x697/frame 0xfffffe012628db50
>> ithread_loop() at ithread_loop+0x187/frame 0xfffffe012628dbb0
>> fork_exit() at fork_exit+0x84/frame 0xfffffe012628dbf0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe012628dbf0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> Uptime: 4d18h45m34s
>> Dumping 24921 out of 131026 
>> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>> 
>> #5  0xffffffff828ee5b7 in ng_snd_item (item=0xfffff8021e3b4d80, 
>> flags=0)
>>     at /usr/src/sys/netgraph/ng_base.c:2252
> 
> It looks like you use some netgraph based ethernet interface.
> The system got received ARP request and is going to send the reply,
> but somehow mbuf with this ARP request has initialized m_next pointer,
> thus it is considered as a chain of mbufs.
> 
> in_arpinput() reuses received mbuf to construct the reply, but it
> doesn't check that an mbut is a chain. It just sets m_len and sends it.
> Then since you have INVARIANTS in your kernel, the netgraph code check
> the actual length of the chain, and it doesn't match to m_len. It 
> panics.


so, is this a bug?  Timing race? Other?

[I] ➜ sudo ngctl list
There are 7 total nodes:
   Name: bce0            Type: ether           ID: 00000001   Num hooks: 
2
   Name: bce1            Type: ether           ID: 00000002   Num hooks: 
0
   Name: bce2            Type: ether           ID: 00000003   Num hooks: 
0
   Name: bce3            Type: ether           ID: 00000004   Num hooks: 
0
   Name: netflow         Type: netflow         ID: 00000006   Num hooks: 
3
   Name: <unnamed>       Type: ksocket         ID: 00000007   Num hooks: 
1
   Name: ngctl3705       Type: socket          ID: 00000008   Num hooks: 
0

ler in ~ at borg
[I] ➜


> 
>> #6  0xffffffff82900c2e in ng_ether_output (ifp=<optimized out>,
>>     mp=0xfffffe012628d578) at /usr/src/sys/netgraph/ng_ether.c:294
>> #7  0xffffffff805b1e43 in ether_output (ifp=<optimized out>,
>>     m=0xfffff81f59eefb00, dst=0xfffffe012628d740, ro=<optimized out>)
>>     at /usr/src/sys/net/if_ethersubr.c:430
>> #8  0xffffffff805cb3e3 in in_arpinput (m=<optimized out>)
>>     at /usr/src/sys/netinet/if_ether.c:1152
>> #9  arpintr (m=0xfffff81f59eefb00) at 
>> /usr/src/sys/netinet/if_ether.c:749
>> #10 0xffffffff805bcf89 in netisr_dispatch_src (proto=4,
>>     source=<optimized out>, m=<unavailable>) at 
>> /usr/src/sys/net/netisr.c:1123
>> #11 0xffffffff805b22d7 in ether_demux (ifp=0xfffff8012c902000,
>>     m=<unavailable>) at /usr/src/sys/net/if_ethersubr.c:913
>> #12 0xffffffff82901045 in ng_ether_rcv_upper (hook=<optimized out>,
>>     item=<optimized out>) at /usr/src/sys/netgraph/ng_ether.c:741
>> #13 0xffffffff828ee6e1 in ng_apply_item (node=0xfffff81054f43400,
>>     item=0xfffff8021e3b4d80, rw=0) at 
>> /usr/src/sys/netgraph/ng_base.c:2403
>> #14 0xffffffff828ee3eb in ng_snd_item (item=0xfffff8021e3b4d80, 
>> flags=0)
>>     at /usr/src/sys/netgraph/ng_base.c:2320
>> #15 0xffffffff828ee6e1 in ng_apply_item (node=0xfffff8012c2d3e00,
>>     item=0xfffff8021e3b4d80, rw=0) at 
>> /usr/src/sys/netgraph/ng_base.c:2403
>> #16 0xffffffff828ee3eb in ng_snd_item (item=0xfffff8021e3b4d80, 
>> flags=0)
>>     at /usr/src/sys/netgraph/ng_base.c:2320
>> #17 0xffffffff82900cbc in ng_ether_input (ifp=<optimized out>,
>>     mp=0xfffffe012628da18) at /usr/src/sys/netgraph/ng_ether.c:255
>> #18 0xffffffff805b34fd in ether_input_internal 
>> (ifp=0xfffff8012c902000,
>>     m=0xfffff81f59eefb00) at /usr/src/sys/net/if_ethersubr.c:654
>> #19 ether_nh_input (m=<optimized out>) at 
>> /usr/src/sys/net/if_ethersubr.c:735
>> #20 0xffffffff805bcf89 in netisr_dispatch_src (proto=5,
>>     source=<optimized out>, m=<unavailable>) at 
>> /usr/src/sys/net/netisr.c:1123
>> #21 0xffffffff805b26f8 in ether_input (ifp=0xfffff8012c902000, m=0x0)
>>     at /usr/src/sys/net/if_ethersubr.c:823
>> #22 0xffffffff8273c7f7 in bce_rx_intr (sc=<optimized out>)
>>     at /usr/src/sys/dev/bce/if_bce.c:6848
>> #23 bce_intr (xsc=0xfffffe01665c2000) at 
>> /usr/src/sys/dev/bce/if_bce.c:8017
>> #24 0xffffffff8047e0e7 in intr_event_execute_handlers (p=<optimized 
>> out>,
>>     ie=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1148
>> #25 ithread_execute_handlers (p=<optimized out>, ie=<optimized out>)
>>     at /usr/src/sys/kern/kern_intr.c:1161
>> #26 ithread_loop (arg=<optimized out>) at 
>> /usr/src/sys/kern/kern_intr.c:1241
>> #27 0xffffffff8047ac74 in fork_exit (
>>     callout=0xffffffff8047df60 <ithread_loop>, arg=0xfffff8012c883100,
>>     frame=0xfffffe012628dc00) at /usr/src/sys/kern/kern_fork.c:1056
>> #28 <signal handler called>
>> (kgdb)
>> 

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler_at_lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Received on Mon Jun 24 2019 - 18:10:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC