Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Jun 2006 16:44:40 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Yar Tikhiy <yar@comp.chem.msu.su>
Cc:        cvs-src@freebsd.org, Maxim Konovalov <maxim@macomnet.ru>, src-committers@freebsd.org, Andre Oppermann <andre@freebsd.org>, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/net if_vlan.c
Message-ID:  <20060629164252.R30355@fledge.watson.org>
In-Reply-To: <20060629152426.GB67682@comp.chem.msu.su>
References:  <200606290752.k5T7qU06021639@repoman.freebsd.org> <20060629132354.D73145@mp2.macomnet.net> <20060629131201.GA67682@comp.chem.msu.su> <44A3E56E.9040705@freebsd.org> <20060629152426.GB67682@comp.chem.msu.su>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 29 Jun 2006, Yar Tikhiy 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.
>>
>> For the time being we should simply mark ifnet's dead but keep them around. 
>> Refcounting is most likely too expensive, especially on larger SMP systems. 
>> All users of ifnets then have to be teached to obey the dead flag.
>
> AFAIK we refcount vnodes, which are an object used rather heavily. Do you 
> think refcounting ifnets would be worse than that?

The specific problem Andre is referencing implicitly is that one of the types 
of objects that references ifnets is the mbuf pkthdr ifnet pointer. 
Obviously, refcount operations for every mbuf ifnet ref/deref would be a big 
problem.  However, nothing says we can't use refcounts for only objects where 
we are willing to pay the expense, such as for encapsulation interfaces, etc, 
however.

Robert N M Watson
Computer Laboratory
University of Cambridge



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060629164252.R30355>