On Thu, 29 Jun 2006, Julian Elischer wrote:
I stress tested gif(4) in the same manner for kicks and got a very similar
panic in in_control(). I suppose that my change eliminated a concurrency
problem in vlan(4) and we began to feel the lack of refcounting at ifnet
level. Indeed, a thread can keep a pointer to an ifnet beyond its lifetime
and panic the system on access to the dead ifnet.
Unfortunatly, since mbufs point to ifnets it is almost impossible to
"efficiently" refcount ifnets. Mbufs may persist almost indefinitly in a
socket receive buffer, well after the given receive interface has gone away.
I submitted patches to full real referenc counting of ifnets in 1995 but it
was already too cumbersom then, and since then it has gotten worse. (due to
SMP etc.)
Partial solutions are possible here -- even if we don't immediately fix the
mbuf pointer issue, we can fix other types of ifnet references to be real,
such as references from heavier weight administrative structures and
operations, even if mbufs don't get them. It's been suggested that interfaces
become dead and be GC'd after a timeout in order to reduce the chances of mbuf
related races. I think this is a pretty reasonable work-around to the general
problem here, especially if "dead" is really implemented properly. An example
of a "bad" implementation of dead would have the ifnet continue to be visible
and occupy space in the interface name space, preventing tun0 from being
immediately reallocated after it is destroyed. A better implementation would
have all external signs of the ifnet disappear, except that the pointer
remains minimally valid for a few seconds. Not ideal, but better than
reference counting ifnets from mbufs. For gif interfaces, etc, real
references are possible and desirable.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
