From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 18:47:20 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 40DD316A4CE; Thu, 23 Sep 2004 18:47:20 +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 D3A0643D31; Thu, 23 Sep 2004 18:47:19 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:d0bf:23a3:52d1:4b5a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AC3431525D; Fri, 24 Sep 2004 03:47:17 +0900 (JST) Date: Fri, 24 Sep 2004 03:47:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Fundakowski Feldman In-Reply-To: <20040922020957.GE84424@green.homeunix.org> References: <20040922020957.GE84424@green.homeunix.org> 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: net@FreeBSD.org Subject: Re: IPv6 route mutex recursion (crash) and fix 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, 23 Sep 2004 18:47:20 -0000 >>>>> On Tue, 21 Sep 2004 22:09:57 -0400, >>>>> Brian Fundakowski Feldman said: > I've already made noise about this before, so I'll be brief. I plan on > committing the following fix that prevents the routing code from being > recursed upon such that RTM_RESOLVE causes the embryonic new route to > be looked up again. I realize that probably no one will bother trying > to see this bug in action, but all you need to do is send some UDP6 to > ff02::1% as a user, with INVARIANTS turned on. > Are there any objections? It would be nice to have this in 5-STABLE, > in case anyone actually wants to have IPv6. The patch itself looks okay with the rationale you explained in a follow-up message. However, I have some related comments. As commented in nd6_rtrequest(), the purpose for checking nd6_is_addr_neighbor() in this function was to avoid creating a neighbor cache for the destination of some special host-routes. For FreeBSD, this can happen with the route which has the RTF_PRCLONING flag. However, since recent versions of FreeBSD (seems to) have got rid of this flag, we might even remove the check in nd6_rtrequest() altogether. (Then we'd not need to modify nd6_is_addr_neighbor().) But removing the check may be too radical and may have unexpected side-effect. Also, it'd be nice if we could keep the difference between the FreeBSD repository code and the KAME snap code as small as possible, in terms of future merge efforts. In this sense, removing the nd6_is_addr_neighbor() check from nd6_rtrequest() might be a suboptimal solution. So, as a result, I tend to think the proposed patch is a reasonable fix to the problem. But please add the rationale as comments, since the background intent is a bit vague as shown by the question from George. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp