Date: Thu, 1 Sep 2005 03:41:19 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Don Lewis <truckman@FreeBSD.org> Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz, imp@bsdimp.com Subject: Re: LOR route vr0 Message-ID: <20050901033730.X83712@fledge.watson.org> In-Reply-To: <200509010209.j8128uvW019560@gw.catspoiler.org> References: <200509010209.j8128uvW019560@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050901033730.X83712>