From owner-freebsd-net Sat Sep 9 12:41:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 33E8837B43F; Sat, 9 Sep 2000 12:41:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13WTsX-0003I6-00; Tue, 05 Sep 2000 19:19:53 -0600 Message-ID: <39B59BB9.22C4BDFE@softweyr.com> Date: Tue, 05 Sep 2000 19:19:53 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Seigo Tanimura Cc: current@freebsd.org, net@freebsd.org Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr References: <14772.34738.630468.85559N@rina> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Seigo Tanimura wrote: > > In ip_output(), imo->imo_multicast_ifp points to the removed > interface, which is passed to IN_LOOKUP_MULTI() to cause a panic. This > problem also occurs when we attempt to delete a multicast address from > a removed interface. if_delmulti() derefers an ifp to the removed > interface, ending up with a panic. The problem does not occur for > unicast. > > http://people.FreeBSD.org/~tanimura/patches/mcastif.diff.gz is a > workround patch. The idea is to track all of the active ifps, confirm > an ifp to be active prior to dereferencing it, and free orphaned > ifmultiaddrs attached to a removed ifp. It would be much more elegant > if we could clean up the multicast information related to a removed > interface, though. Warner Losh pointed out to me: > Tanimura-san did contribute patches. This problem isn't a race at the > eject, but rather the network layer incompletely cleaning up after a > device has gone away. This is, of course, exactly the problem you're looking at. There are several of these cached ifp's hanging around, all causing problems. Robert Watson and I had a nice discussion about how to approach that problem a while back. I've since gotten busy and forgotten about it, as has he (apparently). The quick (-ish) fix I came up with is to double all those cache ifp's all over the code, and always check the first pointer for a null reference before diving off through it. The disadvantage is the check and dereference on every access, the advantage is being able to nullify one pointer in the interface take-down and automagically have all the cached references die. You would leak a single pointer for every interface detach, unless you did reference counting or something like that. The full solution would be to implement ifs a full objects, and to always check the state of the interface before trying to exercise an associated function. It's an ugly problem with no real simple solutions (in C). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message