From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 19:43:47 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3219E16A417 for ; Mon, 3 Sep 2007 19:43:47 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id E0A0813C469 for ; Mon, 3 Sep 2007 19:43:46 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l83JA1iS034484; Mon, 3 Sep 2007 12:10:01 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l83JA1xw034483; Mon, 3 Sep 2007 12:10:01 -0700 (PDT) (envelope-from rizzo) Date: Mon, 3 Sep 2007 12:10:01 -0700 From: Luigi Rizzo To: Vadim Goncharov Message-ID: <20070903121001.B34240@xorpc.icir.org> References: <1261981188838083@webmail15.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vadimnuclight@tpu.ru on Tue, Sep 04, 2007 at 12:50:36AM +0700 Cc: freebsd-ipfw@freebsd.org, "Andrey V. Elsukov" Subject: Re: dummynet / ipfw2: panic, double fault X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 19:43:47 -0000 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