From owner-freebsd-current Sat Nov 2 14: 3:55 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8022D37B401 for ; Sat, 2 Nov 2002 14:03:53 -0800 (PST) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 129CC43E6E for ; Sat, 2 Nov 2002 14:03:53 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0129.cvx21-bradley.dialup.earthlink.net ([209.179.192.129] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1886Mt-0002Em-00; Sat, 02 Nov 2002 14:03:48 -0800 Message-ID: <3DC44B72.5C7C3C5E@mindspring.com> Date: Sat, 02 Nov 2002 14:02:26 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner Cc: current@freebsd.org Subject: Re: crash with network load (in tcp syncache ?) References: <3DC3B701.58AA03ED@mindspring.com> <200211021742.JAA18603@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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