From owner-freebsd-current Fri Nov 1 17: 0:45 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 60F2537B401 for ; Fri, 1 Nov 2002 17:00:44 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEB0B43E4A for ; Fri, 1 Nov 2002 17:00:43 -0800 (PST) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 692E34CE36; Fri, 1 Nov 2002 20:00:43 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA14901; Fri, 1 Nov 2002 20:00:42 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA10356; Fri, 1 Nov 2002 17:00:42 -0800 (PST) Message-Id: <200211020100.RAA10356@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: tlambert2@mindspring.com Subject: Re: crash with network load (in tcp syncache ?) Cc: mime@traveller.cz, current@FreeBSD.ORG References: <200211012246.gA1Mki5n001478@stash.attlabs.att.com> <3DC31EB0.2B79F42E@mindspring.com> Date: Fri, 1 Nov 2002 17:00:40 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d 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 >I think this can still crash (just like my patch); the problem is in >what happens when it fails to allocate memory. Unless you set one of >the flags, it's still going to panic in the same place, I think, when >you run out of memory. No. The flags are only checked when so_head is not NULL. sonewconn() was handing sofree() an inconsistent struct so (so_head was set without being on either queue), i.e. sonewconn() was creating an invalid data structure. The call in sonewconn() used to be to sodealloc(), which didn't care about whether or not the data structure was self-consistent. The code was refactored to do reference counting, but the fact that the socket was inconsistent at that point wasn't noticed until now. The problem is not at all based on what happens in the allocation or protocol attach failure cases. The SYN cache is not involved, this is a bug in sonewconn(), plain and simple. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message