Date: Thu, 27 Jan 2000 09:26:53 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Brett Glass <brett@lariat.org> Cc: security@FreeBSD.ORG Subject: Re: Merged patches Message-ID: <00Jan27.092655est.115219@border.alcanet.com.au> In-Reply-To: <4.2.2.20000125234009.0404f860@localhost>; from brett@lariat.org on Wed, Jan 26, 2000 at 05:50:44PM %2B1100 References: <4.2.2.20000125133808.019fd6a0@localhost> <200001260518.VAA08275@apollo.backplane.com> <4.2.2.20000125234009.0404f860@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-Jan-26 17:50:44 +1100, Brett Glass <brett@lariat.org> wrote: >At 10:18 PM 1/25/2000 , Matthew Dillon wrote: > >> No. There is a time and place for the use of a switch statement to >> cover all your bases, but a *flags* field is *NOT* it. > >Before you assert this so emphatically, allow me to demonstrate. Again, >once 4.0 is frozen, I intend to generate some patches which show what >I have in mind. CS-101: Firstly make it work. Once it works, think about making it faster. I don't think anyone has a problem with you improving the performance of tcp_input.c. The immediate problem is that a defect in FreeBSD's TCP/IP stack, that fairly seriously damages its robustness, has come to light. We need to ensure that this problem does not exist in 4.0-RELEASE - which enters code freeze this weekend. At this point in time, we need a conservative patch - one that is least likely to break something else. Warner's patch seems to meet that requirement with negligible impact on performance (the only impact is a couple of additional tests for multicast source addresses). Your proposal is solely aimed at improving the code efficiency - it does not functionally change the code at all (it is not, by itself, a fix to the RST-flood problem). From this point of view, I don't believe that it would be appropriate to make the changes you are proposing, at this time, for the following reasons: a) It is inappropriate to combine bug-fixes with unrelated efficiency improvements. Doing so just makes it more difficult to work out why the change was made. b) You have not demonstrated that your proposal is actually better than the existing code. The relative behaviour of the different approaches is heavily dependent on the details of how the compiler treats the different code constructs, and how efficiently the CPU executes the resulting object code. c) A larger change introduces more opportunity for accidently introducing a new bug - which is especially undesirable at this point in the release cycle. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Jan27.092655est.115219>