> 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.
You can easily create 2^32 of lots of things on an i386, they just have to take an average of >8 bits each. And this code is _NOT_ restricted to the i386. > > 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. 100/routes a second is trivial to add, this is a straw man argument, you have no idea what this code might be running on, how fast it can add routes, etc, etc. Your using the same mentality that has created the Y2K issue. > > Regarding IPv6, it would be a surprise if that structure remained > the same at all for IPv6. Routes are still going to reference an interface, reference counts are still there. > > > 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. And a strange segfalut is a lot easier to track down and figure out what blew up... NOT!! > > On the other hand, increasing the size of the variable eliminates > the problem entirely. And once you do that, the overflow test is > unnecessary. No, it does not ``eliminate'' the problem, it only hides it. Plain and simple not doing bounds checking on reference counts is bad. -- Rod Grimes - KD7CAX - (RWG25) rgri...@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
