Date: Thu, 31 Jan 2008 21:38:15 +0200 From: Alexander Motin <mav@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> 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 Message-ID: <47A223A7.8030503@FreeBSD.org> In-Reply-To: <20080131.112901.803599757.imp@bsdimp.com> References: <200801310851.m0V8pmNB093625@repoman.freebsd.org> <20080131.112901.803599757.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <200801310851.m0V8pmNB093625@repoman.freebsd.org> > Alexander Motin <mav@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47A223A7.8030503>