Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Aug 2006 10:18:18 -0400
From:      Randall Stewart <rrs@cisco.com>
To:        John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Cc:        freebsd-net@freebsd.org, andre@freebsd.org
Subject:   Re: Problem with uipc_mbuf.c
Message-ID:  <44F44CAA.2000203@cisco.com>
In-Reply-To: <20060828224452.GK37035@funkthat.com>
References:  <44F35A65.3080605@cisco.com> <20060828224452.GK37035@funkthat.com>

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

Ok, I confirmed it...

Changing it to be

atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 1)

Fixes the problem.. no more leaks :-D

R

John-Mark Gurney wrote:
> Randall Stewart wrote this message on Mon, Aug 28, 2006 at 17:04 -0400:
> 
>>	    atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 0) {
> 
> 							 ^
> 
> This should be 1 not 0.. as apparently fetchadd_int returns the old value
> (at least that's what atomic(9) says), which means that if we ever race
> on this comparision, we won't free though we should of...
> 
> if we look at refcount.h, it does:
>         return (atomic_fetchadd_int(count, -1) == 1);
> 
> which release a reference and apparently returns true if it needs to
> be free'd...
> 
> Though the wierd part is that andre, "fixed" it to be 0 in 1.157:
> Fix a logic error introduced with mandatory mbuf cluster refcounting and
> freeing of mbufs+clusters back to the packet zone.
> 
> 
>>I am thinking about restoring the old code.. since
>>it appears to work...
>>
>>Any comments or help would be appreciated..
> 
> 
> Lets see what andre has to say about this.
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)



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