Date: Tue, 13 Aug 2002 05:20:05 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/41552: TCP timers' sysctl's overflow Message-ID: <200208131220.g7DCK5eQ076224@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/41552; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: "G.P. de Boer" <g.p.de.boer@st.hanze.nl> Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/41552: TCP timers' sysctl's overflow Date: Tue, 13 Aug 2002 22:20:22 +1000 (EST) On Tue, 13 Aug 2002, G.P. de Boer wrote: > At 23:43 12-8-2002, Bruce Evans wrote: > > > > Anyway.. it's a integer overflow and it breaks stuff in nasty ways. It's > > > possible to DoS a host with malfunctioning keep-alives: I already had > > > more than 400 hanging connections (in LAST_ACK state) in a few days > > > on a moderately loaded server. The fix is there already, I just think it > > > should be in -RELEASE too. > > > >The overflow was fixed by jdp a couple of weeks ago in -current and > >RELENG_4. It is not fixed in any of the security branches. Do you > >want it there? I think the "fix" for most security bugs caused by > >unusual options is to not use unusual options. > > Ofcourse, unless you haven't got better things to do, which is not ever > the case. > > Now the question pops up if setting HZ -is- unusual. I can imagine that > there are many admins around who turned on polling for extra > performance/robustness and tuned option HZ because LINT says so. Garrett clarified that setting hz to more than 1000 breaks more than the TCP timer sysctls. It violates an RFC. So such setting should be very unusual. But hasn't hz = 1024 been the normal setting on alphas for many years now? As I understand it, you can't set hz using the HZ option on alphas -- the boot firmware decides the clock interrupt frequency and FreeBSD only scales this for stathz, not for hz (which is sort of backwards since a large value for stathz is more useful than a large value of hz except on systems that do too much polling). > As a non-corporate user I can't tell how much people actually did that, but > to me it sounds logical to use polling on heavily loaded networking servers, > which comes with increasing the number of clock-interrupts per second. On > such servers a bug like this is even more dangerous than on my simple > cable-modeming gateway, granted that these systems handle many > connections. I hope using polling is not usual. I think polling is only best in unusual configurations. "Heavily loaded networking servers" might qualify. I have no experience with them, but I have a lot of experience making (non-network) intrerrupt handlers efficient and have never found interrupt overhead per sec to be the main bottleneck in carefully written drivers. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208131220.g7DCK5eQ076224>