Date: Fri, 30 Apr 1999 11:09:03 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: jdp@polstra.com (John Polstra) Cc: freebsd-current@FreeBSD.ORG Subject: Re: Any action on PR 10570 ? getting closer to 65K :-( Message-ID: <199904301809.LAA25759@GndRsh.aac.dev.com> In-Reply-To: <XFMail.990430072914.jdp@polstra.com> from John Polstra at "Apr 30, 99 07:29:14 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> Pierre Beyssac wrote: > > > Wouldn't it be sensible to issue a warning (or panic) when > > increasing the reference count reaches 0, rather than causing a > > later kernel segfault? It would involve some overhead though, and > > I'm not sure having 2^32 routes is currently realistic since most > > machines don't even have that many bytes of RAM, but it might be > > true one day... > > It would be pretty hard to create 2^32 routes, given that IPv4 only > has 32-bit addresses. :-) Also, if you time it I suspect you'll find > that it would take a geological lifetime on a fast machine to add that > many routes. But some of us are playing with IPv6 and it is easy to create >2^32 routes in that environment. > > I think it makes more sense to increase the size of the reference > count as discussed, rather than adding checks that add more complexity > and overhead. The checks could be added _today_ with very little testing needed, simple return an error if attempting to wrap the route ref count from 65536->0. At least then we don't blow chunks latter and end up segfaulting. This is a real bug fix. Even when the variable is increased in size to an int32_t it _should_ have an overflow test, not doing so is poor programming no matter how you cut it. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904301809.LAA25759>