From owner-cvs-all@FreeBSD.ORG Thu Jan 31 19:38:24 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A0C16A418; Thu, 31 Jan 2008 19:38:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7E18013C448; Thu, 31 Jan 2008 19:38:23 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 71302631; Thu, 31 Jan 2008 21:38:22 +0200 Message-ID: <47A223A7.8030503@FreeBSD.org> Date: Thu, 31 Jan 2008 21:38:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "M. Warner Losh" References: <200801310851.m0V8pmNB093625@repoman.freebsd.org> <20080131.112901.803599757.imp@bsdimp.com> In-Reply-To: <20080131.112901.803599757.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/netgraph netgraph.h ng_base.c ng_iface.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 19:38:24 -0000 M. Warner Losh wrote: > In message: <200801310851.m0V8pmNB093625@repoman.freebsd.org> > Alexander Motin writes: > : Implement stack protection based on GET_STACK_USAGE() macro. > : This fixes system panics possible with complicated netgraph setups > : and allows to avoid unneded extra queueing for stack unwrapping. > > How does this help? What are the units? The code is almost entirely > opaque given its magic numbers (100? 64?). It helps perfectly! Numbers are really magic (empirical), they means 80% and 50% of stack used respectively. > Also, if you are checking to see if the stack usage is too big, > it may already be too late. It should not. Most of netgraph nodes actually consume not so much stack, so 20% is more then enough for most. If some specific node consumes more, or it makes heavy outside calls (like border nodes as ng_iface or ng_ksocket) it should be declared as HI_STACK to make sure that at least half of stack will be available for it. There will always be some part of magic as nobody can say for sure how much stack is required to pass packet via all network stack to TCP socket and then back. But while netgraph engine allows to decouple stack without consequences I thing it worth to make it work. Without this patch it was not hard to make the mpd setup that will crash the system due to stack overflow by the usual ping packet. Now I am unable to reproduce this. -- Alexander Motin