dummynet / ipfw2: panic, double fault

Vadim Goncharov vadimnuclight at tpu.ru
Mon Sep 3 10:50:43 PDT 2007


03.09.07 @ 23:48 Andrey V. Elsukov wrote:

> I got a trace for this fault.
> dummynet reinject packet to the ip_input through netisr_dispath.
> This procedure was done success several times, but in the next time
> it's fault.

> (kgdb) p &ipfw_chk
> $1 = (int (*)(struct ip_fw_args *)) 0xc3374ea0 <ipfw_chk>
> (kgdb) l *(0xc3374ea0+0x16)
> 0xc3374eb6 is in ipfw_chk  
> (/usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2304).
> 2299             * ip   is the beginning of the ip(4 or 6) header.
> 2300             *      Calculated by adding the L3offset to the start  
> of data.
> 2301             *      (Until we start using L3offset, the packet is
> 2302             *      supposed to start with the ip header).
> 2303             */
> 2304            struct mbuf *m = args->m;
> 2305            struct ip *ip = mtod(m, struct ip *);
>
> I don't understand why we have panic here..
> Can someone explain this panic?

We have repeating groups of calls for several times, ending in:

> dblfault_handler() at dblfault_handler+0x9b
> --- trap 0x17, eip = 0xc3343eb6, esp = 0xd4f80f7c, ebp = 0xd4f8127c ---
> ipfw_chk(d4f81294,41ec0d7e,0,0,c30de000,...) at ipfw_chk+0x16

As we can see from comment in /sys/i386/i386/trap.c:

  * Double fault handler. Called when a fault occurs while writing
  * a frame for a trap/exception onto the stack. This usually occurs
  * when the stack overflows (such is the case with infinite recursion,
  * for example).

That's look like our case, repeating calls, as in infinite recursion. I  
suppose that interrupt thread's stack in the kernel is too small for this  
case. Quick-n-dirty hackish solution could be increasing stack size, but  
that could be overriden by another bunch of rules. Alas, I am not a  
VM/netisr guru to find the right way...

-- 
WBR, Vadim Goncharov


More information about the freebsd-ipfw mailing list