Skip site navigation (1)Skip section navigation (2)
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 +0700
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: <http://docs.FreeBSD.org/cgi/mid.cgi?20070903121001.B34240>