From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 20:45:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EC2E16A4D0 for ; Thu, 30 Sep 2004 20:45:05 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8156343D3F for ; Thu, 30 Sep 2004 20:45:04 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7677F1525D; Fri, 1 Oct 2004 05:45:01 +0900 (JST) Date: Fri, 01 Oct 2004 05:45:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: snap-users@kame.net Subject: Re: (KAME-snap 8820) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 20:45:05 -0000 >>>>> On Thu, 30 Sep 2004 12:04:05 +0300 (EEST), >>>>> Pekka Savola said: >> > Unfortunately, I can't. The when my SSH session froze, and the 6to4 >> > SSH sessions as well, my first instinct was 'oh, crap', and knee-jerk >> > push of reset button (because the box has no keyboard attached). Sorry >> > for being inprecise. >> >> Okay, I just found a bug that only happens when ip6.rtexpire is 0. >> Please try the following patch (with rtexpire=0). > Well, the box no longer crashed at least, so I'd guess it works. :-) Glad to hear that. > Btw, is there any particular reason why net.inet.ip.rtexpire > automatically dynamically re-adjusts itself (here, it's typically > around 10 or 12), while net.inet6.ip6.rtexpire does not? Hmm, good point. I was also wondering why such a massive number of route entries remained despite the periodical cleanup mechanism. Then I found another bug, which set the cleanup interval to a huge value (almost infinite in a practical sense). The patch below, including the previous fix, should also solve the problem (I must confess I even did not compile it, so please be careful). Perhaps you can then live with the original rtexpire value. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Index: in6_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v retrieving revision 1.1.2.3 diff -u -r1.1.2.3 in6_rmx.c --- in6_rmx.c 28 Apr 2002 05:40:27 -0000 1.1.2.3 +++ in6_rmx.c 30 Sep 2004 20:40:14 -0000 @@ -270,10 +270,16 @@ rt->rt_flags |= RTPRF_OURS; rt->rt_rmx.rmx_expire = time_second + rtq_reallyold; } else { + struct rtentry *dummy; + + /* + * rtrequest() would recursively call rtfree() without the + * dummy entry argument, causing duplicated free. + */ rtrequest(RTM_DELETE, (struct sockaddr *)rt_key(rt), rt->rt_gateway, rt_mask(rt), - rt->rt_flags, 0); + rt->rt_flags, &dummy); } } @@ -379,7 +385,7 @@ } atv.tv_usec = 0; - atv.tv_sec = arg.nextstop; + atv.tv_sec = arg.nextstop - time_second; timeout(in6_rtqtimo, rock, tvtohz(&atv)); }