From owner-freebsd-net Tue Sep 5 11:44:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B10EF37B424; Tue, 5 Sep 2000 11:44:21 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA27368; Tue, 5 Sep 2000 12:44:17 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA62492; Tue, 5 Sep 2000 12:43:35 -0600 (MDT) Message-Id: <200009051843.MAA62492@harmony.village.org> To: Robert Watson Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr Cc: Wes Peters , Seigo Tanimura , current@FreeBSD.ORG, net@FreeBSD.ORG In-reply-to: Your message of "Tue, 05 Sep 2000 14:38:54 EDT." References: Date: Tue, 05 Sep 2000 12:43:35 -0600 From: Warner Losh Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Robert Watson writes: : This is all made harder by the fact that struct mbuf has a struct ifnet : pointer in it, so if for any reason there is an outstanding mbuf : originating from that interface, it is possible that the struct ifnet * : will be dereferenced. For example, if it hits an ipfw rule that dummynets : it, then hits an interface-based rule. Yes. That's true. There's a race. : This has been raised as an issue before, and is a good reason to ifconfig : down the interface, and wait a second or two before ejecting. You could : imagine code-based solutions, including scanning mbufs (?) for pointers : that are undesirable, refcounting the struct ifnet so it isn't freed until : all mbufs are free'd, etc. Whatever the case, you want to make sure that : locking in the line of fire is avoided (i.e., attempting to lock struct : ifnet during packet handling in the interrupt). No body waits :-(. This is made worse by pccard's detaching the device when a suspend happens via acpi or apm. NetBSD has done some interesting things in this area with reference counting and such that I'd love to bring in as soon as I get newcard done. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message