From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 07:39:51 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 A19F716A4CE; Wed, 22 Sep 2004 07:39:51 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54C3E43D49; Wed, 22 Sep 2004 07:39:51 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 39EC3653B5; Wed, 22 Sep 2004 08:39:50 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39063-01-3; Wed, 22 Sep 2004 08:39:49 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-185-245.dsl.snfc21.pacbell.net [64.171.185.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 1E05D653AD; Wed, 22 Sep 2004 08:39:49 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 1DC7A6455; Wed, 22 Sep 2004 00:39:46 -0700 (PDT) Date: Wed, 22 Sep 2004 00:39:46 -0700 From: Bruce M Simpson To: Brian Fundakowski Feldman Message-ID: <20040922073946.GC4985@empiric.icir.org> References: <20040922020957.GE84424@green.homeunix.org> <20040922025320.GF84424@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040922025320.GF84424@green.homeunix.org> 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: Wed, 22 Sep 2004 07:39:51 -0000 On Tue, Sep 21, 2004 at 10:53:20PM -0400, Brian Fundakowski Feldman wrote: > Sorry, I should have provided a higher number of lines of context. > It prevents a call to nd6_lookup() and reentry into the route table > when entered via RTM_RESOLVE. I.e. nd6_rtrequest(), nd6_is_addr_neighbor(), > nd6_lookup(). I haven't tested your patch but the rationale for this sounds fine. Recursive locking attempts via the lookup code by way of neighbour discovery is a Bad Thing, and it would be useful to keep these semantics working for IPv6. So it looks good to me. BMS