Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 04 Sep 2007 00:50:36 +0700
From:      "Vadim Goncharov" <vadimnuclight@tpu.ru>
To:        "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-ipfw@freebsd.org
Subject:   Re: dummynet / ipfw2: panic, double fault
Message-ID:  <optx3aimzu4fjv08@nuclight.avtf.net>
In-Reply-To: <1261981188838083@webmail15.yandex.ru>
References:  <1261981188838083@webmail15.yandex.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?optx3aimzu4fjv08>