Date: Mon, 3 Sep 2007 12:10:01 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Vadim Goncharov <vadimnuclight@tpu.ru> Cc: freebsd-ipfw@freebsd.org, "Andrey V. Elsukov" <bu7cher@yandex.ru> Subject: Re: dummynet / ipfw2: panic, double fault Message-ID: <20070903121001.B34240@xorpc.icir.org> In-Reply-To: <optx3aimzu4fjv08@nuclight.avtf.net>; from vadimnuclight@tpu.ru on Tue, Sep 04, 2007 at 12:50:36AM %2B0700 References: <1261981188838083@webmail15.yandex.ru> <optx3aimzu4fjv08@nuclight.avtf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 04, 2007 at 12:50:36AM +0700, Vadim Goncharov wrote: > 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. ... > 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... interesting analysis - but if that is the case i don't understand why the netisr_dispatch routine is called recursively instead of waiting for the previous handler (which is the one who makes the 'recursive' call) to terminate - without looking at the code, i would think that there is a lock of some kind to prevent this ? cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070903121001.B34240>