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