From owner-freebsd-current@FreeBSD.ORG  Wed Nov 26 10:46:19 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from green.bikeshed.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 7C38416A4CE
	for <current@FreeBSD.org>; Wed, 26 Nov 2003 10:46:19 -0800 (PST)
Received: from green.bikeshed.org (green@localhost [127.0.0.1])
	by green.bikeshed.org (8.12.10/8.12.9) with ESMTP id hAQIkIQn028554
	for <current@FreeBSD.org>; Wed, 26 Nov 2003 13:46:18 -0500 (EST)
	(envelope-from green@green.bikeshed.org)
Received: from localhost (green@localhost)hAQIkH7C028549
	for <current@FreeBSD.org>; Wed, 26 Nov 2003 13:46:17 -0500 (EST)
Message-Id: <200311261846.hAQIkH7C028549@green.bikeshed.org>
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
X-Exmh-Isig-CompType: comp
X-Exmh-Isig-Folder: inbox
To: current@FreeBSD.org
From: Brian Fundakowski Feldman <green@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain
Date: Wed, 26 Nov 2003 13:46:16 -0500
Sender: green@green.bikeshed.org
Subject: IPv6 locking crash (recursion)
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: Wed, 26 Nov 2003 18:46:19 -0000

Has anyone else tried out the most basic IPv6 test: ndp -I <iface> and
then ping6 fe80::<normal address without %<iface> extension>? I was
greeted by recursion on a non-recursive lock. After some sleuthing,
I tried to determine what conditions could be tested for that would
indicate "this must not call the nd6_is_addr_neighbor() call because
we're from a normal RTM_RESOLVE initializing a new route", and this
is the most correct thing I can come up with. It actually would do
something entirely different if recursion were allowed. Comments?

Index: nd6.c
===================================================================
RCS file: /u/FreeBSD-cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.37
diff -u -r1.37 nd6.c
--- nd6.c	8 Nov 2003 23:36:32 -0000	1.37
+++ nd6.c	26 Nov 2003 13:45:45 -0000
@@ -1095,7 +1095,8 @@
 
 	if (req == RTM_RESOLVE &&
 	    (nd6_need_cache(ifp) == 0 || /* stf case */
-	     !nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp))) {
+	    ((!(rt->rt_flags & RTF_WASCLONED) || rt->rt_flags & RTF_LLINFO) &&
+	    !nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp)))) {
 		/*
 		 * FreeBSD and BSD/OS often make a cloned host route based
 		 * on a less-specific route (e.g. the default route).