From owner-freebsd-current@FreeBSD.ORG  Thu Nov 27 14:48:17 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 E0B3F16A4CE
	for <freebsd-current@freebsd.org>;
	Thu, 27 Nov 2003 14:48:17 -0800 (PST)
Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch
	[62.48.0.70])	by mx1.FreeBSD.org (Postfix) with ESMTP id 77E5243FCB
	for <freebsd-current@freebsd.org>;
	Thu, 27 Nov 2003 14:48:16 -0800 (PST)
	(envelope-from andre@freebsd.org)
Received: (qmail 6185 invoked from network); 27 Nov 2003 21:46:23 -0000
Received: from unknown (HELO freebsd.org) ([62.48.0.54])
          (envelope-sender <andre@freebsd.org>)
          by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP
          for <freebsd-current@freebsd.org>; 27 Nov 2003 21:46:23 -0000
Message-ID: <3FC67F2E.EBF83B89@freebsd.org>
Date: Thu, 27 Nov 2003 23:48:14 +0100
From: Andre Oppermann <andre@freebsd.org>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Fix for 5.2-BETA lockup problems
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Nov 2003 22:48:18 -0000

Hello all,

I've found what probably is going wrong in tcp_hostcache.  The problem is me
cutting corners (what goes around comes around...) in tcp_hc_insert when the
bucket limit is reached.  I made the #if 0 too big and the bucket was not
removed from the tailqueue when we hit the bucket limit.  A couple of lines
later it is inserted again as head element which leads to an infinite loop
either when the next lookup on the same bucket row is done, or when the
the tcp_hc_purge function is run to timeout the entries.

Please try the attached patch which should fix it.

-- 
Andre


Index: tcp_hostcache.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/tcp_hostcache.c,v
retrieving revision 1.1
diff -u -p -r1.1 tcp_hostcache.c
--- tcp_hostcache.c     20 Nov 2003 20:07:38 -0000      1.1
+++ tcp_hostcache.c     27 Nov 2003 20:23:06 -0000
@@ -354,11 +354,11 @@ tcp_hc_insert(struct in_conninfo *inc)
                 * maybe we drop something that is still "in-use" but we can
                 * be "lossy".
                 */
-#if 0
                TAILQ_REMOVE(&hc_head->hch_bucket, hc_entry, rmx_q);
-               uma_zfree(tcp_hostcache.zone, hc_entry);
                tcp_hostcache.hashbase[hash].hch_length--;
                tcp_hostcache.cache_count--;
+#if 0
+               uma_zfree(tcp_hostcache.zone, hc_entry);
 #endif
                tcpstat.tcps_hc_bucketoverflow++;
        } else {