Date: Tue, 05 Sep 2000 23:34:02 -0700 From: Julian Elischer <julian@elischer.org> To: Warner Losh <imp@village.org> Cc: Robert Watson <rwatson@FreeBSD.ORG>, Wes Peters <wes@softweyr.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, 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: <39B5E55A.167EB0E7@elischer.org> References: <Pine.NEB.3.96L.1000905143626.2846B-100000@fledge.watson.org> <200009051843.MAA62492@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
>
> 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.
A few years ago I did some work on rationalising the reference counting
in
the kernel WRT network routes and ifps.
Some of it was actually checked in on a branch, however it
should probably be done from scratch since so much has changed.
the basic things I did were:
ALL references to ifps were counted
(mbufs too, though that was never checked in)
References to ifnets in many structures were changed to be
references to ifaddrs attached to the ifnets instead.
Ifaddrs and ifnet structs had a 'VALID' flag added to them.
Whenever a new pointer to an ifnet/ifaddr was followed, the VALID flag
was checked.
if the VALID flag was not set then the operation was aborted and the
reference being followed was dropped. (on reaching 0 the target was
freed).
If you freed an interface, then the structures would hang around as long
as they had refering pointers outstanding. This could possibly lead to a
leak,
but that would by definition also be a leak of mbufs or routes. The
ifaddrs
also had references to the ifps. However on boing made invalid,
they dropped those references immediatly. so theoretically,
since many structs pointed to ifaddrs instead of ifnets, it would be
quite possible for the ifnet structs to be freed long before an ifaddr
that was once attached to it. (this was safe because the VALID flag
was not set in the ifaddr, so nothing would follow the pointer.
(which was NULLED out anyhow).
I had a set of small methods to do these dereferences and stuff,
but the hardest part was deciding in the CALLING routines (e.g.
ipoutput)
what to do when you discovered that the ifnet you were going to access
came back as INVALID).
Note that this didn't totally close the window for disaster
as it is possible that an interface might be disabled between the
time that you followed the ifp and the time that you used the pointer.
it took it down to millisecconds however as opposed to seconds.
I think it would be possible using sufficiently paranoid coding
to completely close the window, but the question is raised
"how much time do you want to waste in normal operation
being paranoid?"
With SMP the windows widen again, so we need to think a lot about this.
Maybe all Interface removals are not done directly but handled in a
serialised manner by some kernel thread? This feeds into what I believe
should be done in the general case of device removal, which is the
creation of a devd kernel thread, that responds to requests from drivers
to
instatiate and deinstanciate system linkages. having this done by the
drivers themselves raises so many complications WRT locking and
such that I think it would be a win overall.
The drivers would supply code to be run by the devd, using methods
supplied by the devd.
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Perth
v
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?39B5E55A.167EB0E7>