From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 02:41:21 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0165D16A41F; Thu, 1 Sep 2005 02:41:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF4A443D46; Thu, 1 Sep 2005 02:41:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id CD01546B9F; Wed, 31 Aug 2005 22:41:19 -0400 (EDT) Date: Thu, 1 Sep 2005 03:41:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Don Lewis In-Reply-To: <200509010209.j8128uvW019560@gw.catspoiler.org> Message-ID: <20050901033730.X83712@fledge.watson.org> References: <200509010209.j8128uvW019560@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 02:41:21 -0000 On Wed, 31 Aug 2005, Don Lewis wrote: > If you are finding that you need to wire the order of if_addr_mtx, that > is a potential clue. The only lock I see taken after if_addr_mtx is > "UMA zone". If you are seeing other locks under if_addr_mtx, maybe one > of those is looping back to rtentry. I also see taskqueue, "if send > queue", and various memory subsystem locks under "network driver". > Both taskqueue and "if send queue" appear to be leaf locks. In the link layer multicast address code, I'm fairly careful not to hold if_addr_mtx over calls into the ifnet code. Three suspect points are the call to ifp->if_resolvemulti(), which looks like it is OK for all current implementations, and the call to rt_newmaddrmsg() in if_addmulti(), which is made before the unlock call so that the 'ifma' reference remains valid, and a similar call to rt_newmaddrmsg() in if_delmulti(). These calls should acquire only mbuf allocator and general allocator locks, and the netisr handoff mutex for NETISR_ROUTE. However, perhaps there's a case here I'm not seeing. It might be worth commenting out those two calls under if_addr_mtx and seeing if the lock order warning goes away. Robert N M Watson