cvs commit: src/sys/net if_vlan.c
brooks at one-eyed-alien.net
Mon Jul 3 20:34:01 UTC 2006
On Fri, Jun 30, 2006 at 12:01:23PM +0100, Robert Watson wrote:
> 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
> >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.
The goal of the work to remove the ifnet from the softc was that we
would end up in a situation where if_free (or if_detach if we remove
if_free) would cause the interface to have all it's state set to safe
but dead values and remove it from the ifnet list. At that point access
by pointer or index would still work, but ifconfig wouldn't see it
since it would not be on the ifnet list and syscalls, sysctl, or ioctls
that access interfaces by would be modified to detect the dead state
and act as though the interface is not there. We could then consider
either holding the interface for a configurable or computed length
of time or adding some sort of refcounting (probably impractical).
In practice ifnet and indexes are pretty cheap so holding on to an
interface for up to a couple minutes should be OK in most cases. For
some applications (really massive tunnel brokers) it might be beneficial
to change if_index from a u_short to an int to increase the available
set. I'd been meaning to work on this, but real life has interfered.
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20060703/56a5d3b5/attachment.pgp
More information about the freebsd-net