From owner-freebsd-net@FreeBSD.ORG Fri May 1 15:36:15 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E11A410656F6 for ; Fri, 1 May 2009 15:36:15 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B84C18FC26 for ; Fri, 1 May 2009 15:36:15 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0005833845D for ; Fri, 1 May 2009 11:36:14 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 01 May 2009 11:36:14 -0400 X-Sasl-enc: aH7zlgAX4Fp4Mluui+7t/oijs/SEC8xx14Lp2b8QnCAE 1241192174 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4D2B5D3F8 for ; Fri, 1 May 2009 11:36:14 -0400 (EDT) Message-ID: <49FB16ED.1070909@incunabulum.net> Date: Fri, 01 May 2009 16:36:13 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: LOR in ip6_output() and MLDv2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 15:36:16 -0000 Hi all, There is a Lock Order Reversal in ip6_output(), which is triggered by the MLDv2 code. What's the best way to resolve? IF_AFDATA_LOCK could be changed to an rwlock, that might help get rid of it -- ip6_output() will take an exclusive lock by way of in6_setscope(), which is needed as ip6_output() does not accept an ifp. in6_setscope() acquires the IF_AFDATA_LOCK and the SCOPE6_LOCK. It does not write to anything. MLD tries to side-step the use of in6_setscope() with the MLD lock held, but this is not enough because ip6_output() will still need to call in6_setscope() to verify the scope ID which MLD gives to it is not bogus (even though in the KAME stack, this just amounts to an embedded ifindex). The LOR is probably benign, but it exists because the bottom half of IPv6 is taking mutex locks on ifnet's if_afdata field. It is triggered because _domifattach() is always called with the IF_AFDATA lock held, and it takes the MLI_LOCK during initialization. WITNESS sees this lock order and notes it down, it then triggers a LOR on if detach. I'd rather not introduce a netisr for an output queue, as forcing deferred dispatch (to get away from the LOR) is undesirable and could lead to further races on VIMAGE detach, for example. cheers, BMS