Date: Tue, 05 Sep 2000 19:19:53 -0600 From: Wes Peters <wes@softweyr.com> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> 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 Message-ID: <39B59BB9.22C4BDFE@softweyr.com> References: <14772.34738.630468.85559N@rina>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39B59BB9.22C4BDFE>