From owner-freebsd-current Fri Apr 30 11:10:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 4373114DD6 for ; Fri, 30 Apr 1999 11:10:19 -0700 (PDT) (envelope-from rgrimes@GndRsh.aac.dev.com) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.8/8.8.8) id LAA25759; Fri, 30 Apr 1999 11:09:03 -0700 (PDT) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199904301809.LAA25759@GndRsh.aac.dev.com> Subject: Re: Any action on PR 10570 ? getting closer to 65K :-( In-Reply-To: from John Polstra at "Apr 30, 99 07:29:14 am" To: jdp@polstra.com (John Polstra) Date: Fri, 30 Apr 1999 11:09:03 -0700 (PDT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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