Date: Tue, 4 Sep 2007 13:20:06 GMT From: Bruce M Simpson <bms@incunabulum.net> To: freebsd-net@FreeBSD.org Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client Message-ID: <200709041320.l84DK6nr077445@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/116077; it has been noted by GNATS. From: Bruce M Simpson <bms@incunabulum.net> To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client Date: Tue, 04 Sep 2007 14:17:53 +0100 I wrote this, but I may not have time to fix it, because I need to do work other than FreeBSD to support myself. I have no idea what an elvin or avis is. It isn't clear to me how you are triggering this panic, it looks like you are removing or tearing down interfaces from the system? Are you using a network driver which has IFF_NEEDSGIANT set? Unfortunately because the ifp lock has to be taken before other locks if IFF_NEEDSGIANT is set, it dereferences the ifp provided which may have already gone away. The link layer multicast code will try to invalidate the ifp pointer in the underlying ifma. However in this case the cached ifp used is the one in struct in_multi. Try the following. Change 1063 ifp = inm->inm_ifp; 1064 IFF_LOCKGIANT(ifp); 1065 IN_MULTI_LOCK(); ... to ifp = inm->inm_ifma->ifp; if (ifp != NULL) IFF_LOCKGIANT(ifp); ... and put if (ifp != NULL) IFF_UNLOCKGIANT(ifp); at the end of the function. It is safe to deref inm->inm_ifma as ifma is refcounted. The real fix is to either eliminate Giant completely or to implement reference counting for struct ifnet. I should point out that this code gets rewritten for IGMPv3. Please let me know if this works around the issue. If it doesn't, I'll leave it to someone else for now - there should be enough in here to go on.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709041320.l84DK6nr077445>