Date: Sat, 02 Nov 2002 14:02:26 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bill Fenner <fenner@research.att.com> Cc: current@freebsd.org Subject: Re: crash with network load (in tcp syncache ?) Message-ID: <3DC44B72.5C7C3C5E@mindspring.com> References: <Pine.BSF.4.41.0211020937210.87031-100000@prg.traveller.cz> <3DC3B701.58AA03ED@mindspring.com> <200211021742.JAA18603@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fenner wrote: > I think most of your 9k of reasoning is based on the thought that > soreserve() allocates memory. It doesn't, and never has. The real problem is the in_pcballoc() in tcp_attach(), which calls uma_zalloc(). But for mbufs, soreserve allocates space, for potential mbufs, even though it does not itself allocate mbufs. I didn't want to go through the whole state machine to explain the additional failure modes, so I simplified. Consider the case where you receive network interrupts for packets containing data on partially complete, or in-the-process-of sockets, while you are in the middle of running the NETISR. This code was not written to be reentrant in the failure case, and the SYN cache adds this requirement. The only "safe" way to do this, with the code unmodified, is to hold splbio() around the calls, and split the "if" test I modified into an if .. if..else .. else if..else. Even then, it doesn't make one call that give a binary success/fail. As evidence, I offer that my fix works, too, by changing the order of operation. 8-). Note that I'm not complaining about your fix any more than I'm complaining about mine -- in fact, I have stated repeatedly for the record that your fix has one less failure mode than my fix, and should be committed. Potentially, both of them should be committed (for the SYN cache disable case, mine suppresses another panic, for the other, yours suppresses a different panic, and "enabled" is the common case). It's just that neither address the real problem, they just suppress the side effect of a side effect, in different ways. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC44B72.5C7C3C5E>