From owner-freebsd-security Tue Jan 25 9:38:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 83E1B15343 for ; Tue, 25 Jan 2000 09:38:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA04802; Tue, 25 Jan 2000 09:38:14 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Jan 2000 09:38:14 -0800 (PST) From: Matthew Dillon Message-Id: <200001251738.JAA04802@apollo.backplane.com> To: Warner Losh Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: Merged patches References: <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :By what code paths is this possible? Please be specific. : :: Also, in at least one place (maybe more), the code does :: multiple tests of the TCP option flags in succession. :: Several tests of this kind should generally be merged :: into a switch for speed (the many conditional jumps :: cause pipeline stalls on many processors, especially :: older ones) and readability. : :It does? If so, it certainly doesn't ADD them. So we do multiple tests, so what? Not only will GCC potentially optimize the code, but doing multiple tests means the memory references are already in the L1 cache so, frankly, I doubt you would save more then a few nanoseconds glomming it all together into a switch. In fact, it's quite possible that attempting to optimize it in this fashion will actually make it slower since you have no control over the critical path when you glom things into a switch statement. It makes no sense at all to mess around with working code just to save a few nanoseconds. -Matt Matthew Dillon :: In short, I'd only go with this patch as-is if my :: purpose were to minimize the changes made before :: release. If this were the goal, I'd go back to the :: code immediately thereafter and try to tackle some :: of the inefficiencies and holes in this key input :: path more aggressively. : :Yes. That's exactly the goal. : :Like I said in my initial mail, I may remove the ICMP_BANDLIM option :as an option, but bump the rate limiter to 1000. But that's about as :far as I'd be willing to go at this time. : :Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message