On 25.06.2019 15:59, Larry Rosenman wrote:
> On 06/25/2019 4:18 am, Andrey V. Elsukov wrote:
>> On 24.06.2019 23:10, Larry Rosenman wrote:
>>>>> #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 think we should determine that my assumption is correct :)
>> Can you show the output of the following commands from the kgdb for this
>> core?
>>
>> (kgdb) f 7
>> (kgdb) p *m
>> (kgdb) p *m->m_next
>
>
> (kgdb) fr 7
> #7 0xffffffff805b1e43 in ether_output (ifp=<optimized out>,
> m=0xfffff81f59eefb00, dst=0xfffffe012628d740, ro=<optimized out>) at
> /usr/src/sys/net/if_ethersubr.c:430
> 430 if ((error = (*ng_ether_output_p)(ifp, &m)) != 0) {I failed to track the possible way to get this. Please, show the output of the following commands: (kgdb) f 7 (kgdb) p/x (u_char[42])m->m_data (kgdb) p/x (u_char[1372]m->m_next->m_data Did you used this configuration for the long time and these panics were the first time? -- WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
