From owner-cvs-src@FreeBSD.ORG Fri Feb 1 00:58:38 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B9716A419; Fri, 1 Feb 2008 00:58:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 085CB13C46A; Fri, 1 Feb 2008 00:58:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m110u8IF013959; Thu, 31 Jan 2008 17:56:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 31 Jan 2008 17:57:13 -0700 (MST) Message-Id: <20080131.175713.1102545018.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <47A223A7.8030503@FreeBSD.org> References: <200801310851.m0V8pmNB093625@repoman.freebsd.org> <20080131.112901.803599757.imp@bsdimp.com> <47A223A7.8030503@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2008 00:58:38 -0000 In message: <47A223A7.8030503@FreeBSD.org> Alexander Motin writes: : 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. Comments about this should be made. How the heck is one supposed to know these mappings... : > 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. I understand it is useful, but it should be better commented, follow style(9) better and have a warning that it isn't perfect. Checking to see if you've overflowed based on how much space you are now using is always fraught with danger... Some early 'buffer overflow' "fixes" did this, and in that scenario clearly once you've overflowed, it is too late to check... Warner