Date: Sun, 4 Apr 2004 15:01:55 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/net if_gif.c Message-ID: <Pine.NEB.3.96L.1040404150046.84672A-100000@fledge.watson.org> In-Reply-To: <20040404051126.GA22393@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040404150046.84672A-100000>