cvs commit: src/sys/net if_gif.c

[Robert Watson]

On Sat, 3 Apr 2004, Brooks Davis wrote:

> > Actually, just replacing nesting limiter with loop detection was a
> > bad idea, so I didn't follow it.  It's a bad idea because you might
> > have many nesting (but not looping) gif interfaces, and this will
> > still cause panic by exhausting the kernel stack.  Instead, I have
> > combined both checks.  Please review the attached patch.
> 
> Unless you can automaticly choose a valid value for max_gif_nesting, I
> think it should be taken out and shot.  Unless you can do that, there's
> nothing you can do to prevent the admin from making a configuration that
> blows out the stack so why keep the extra annoyance of gif_max_nest
> around?  It won't do anything to prevent the panic and will break things
> in perfectly valid cases.  If we're really worried about the stack
> issue, forcing a requeue instead of processing to completion any time
> we're nested makes more sense to me. 

Agreed -- I suspect that decapsulation should almost always re-queue
rather than process inline.  However, you still need loop detection that
carries state for the packets as it gets processed.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research