From owner-freebsd-net Sat Sep 9 12:41:49 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 806C937B506; Sat, 9 Sep 2000 12:41:26 -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 13WS4m-0003Gf-00; Tue, 05 Sep 2000 17:24:24 -0600 Message-ID: <39B580A8.CE59B5CF@softweyr.com> Date: Tue, 05 Sep 2000 17:24:24 -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: Warner Losh Cc: Seigo Tanimura , 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: <39B51375.4DE4C6FA@softweyr.com> <39B48F1E.4C193F79@softweyr.com> <14772.34738.630468.85559N@rina> <200009050609.AAA58464@harmony.village.org> <200009051535.JAA60822@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message <39B51375.4DE4C6FA@softweyr.com> Wes Peters writes: > : state the code is in now, and if someone wants it to be better, we await > : their patches. As always. ;^) > > 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. 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 reference counting in the if 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