Date: Fri, 24 Sep 2004 03:47:22 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: Brian Fundakowski Feldman <green@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: IPv6 route mutex recursion (crash) and fix Message-ID: <y7vu0tokekl.wl@ocean.jinmei.org> In-Reply-To: <20040922020957.GE84424@green.homeunix.org> References: <20040922020957.GE84424@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Tue, 21 Sep 2004 22:09:57 -0400, >>>>> Brian Fundakowski Feldman <green@FreeBSD.org> 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%<if> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vu0tokekl.wl>