cvs commit: src/sys/netgraph netgraph.h ng_base.c ng_iface.c

[M. Warner Losh]

In message: <47A223A7.8030503 at FreeBSD.org>
            Alexander Motin <mav at FreeBSD.org> writes:
: M. Warner Losh wrote:
: > In message: <200801310851.m0V8pmNB093625 at repoman.freebsd.org>
: >             Alexander Motin <mav at 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.

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