Date: Fri, 30 Apr 1999 11:20:19 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Any action on PR 10570 ? getting closer to 65K :-( Message-ID: <XFMail.990430112019.jdp@polstra.com> In-Reply-To: <199904301809.LAA25759@GndRsh.aac.dev.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Rodney W. Grimes wrote: >> 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. You're being totally unrealistic. You can't create >2^32 of _anything_ on an i386 without running out of memory. Even if you could address that much memory, you or your machine would be dead from old age long before it managed to add that many routes. Let's say, _totally_ unrealistically, that you added 100 routes per second continuously. It would still take you 500 days to wrap the 32-bit counter. Regarding IPv6, it would be a surprise if that structure remained the same at all for IPv6. > 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. No it's not. It doesn't fix anything, because your 16-bit counter has wrapped around and now it's not valid any more. It doesn't matter whether you detect it and warn about it or not. The damage is already done. On the other hand, increasing the size of the variable eliminates the problem entirely. And once you do that, the overflow test is unnecessary. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong 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?XFMail.990430112019.jdp>