Date: Thu, 07 Sep 2006 15:19:40 -0400 From: Randall Stewart <rrs@cisco.com> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Problem with uipc_mbuf.c Message-ID: <450070CC.7070701@cisco.com> In-Reply-To: <44F9386A.30804@freebsd.org> References: <44F35A65.3080605@cisco.com> <20060828224452.GK37035@funkthat.com> <44F45A2A.8030405@freebsd.org> <20060902081043.J32527@mp2.macomnet.net> <44F9386A.30804@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andre:
Without the "fix" SCTP leaks mbufs when
running netpipe.. for some reason my other
tests (utilites) do not do so.. but I think
it has to do with the back-and-forth nature
of netpipe.. it sends and then receives constantly
while most of the other things I play with have a
source and a sink..
Anyway.. without the fix we leak clusters like
crazy on a SMP machine.. maybe not like crazy.. but
at least 1 cluster per every few megabytes transfered
by netpipe..
I think the fix is really quite good.. it will
only affect you if you have multiple CPU's operating
on the mbuf (mfree()) at the same time..
The majority case takes the first part of the if..
R
Andre Oppermann wrote:
> Maxim Konovalov wrote:
>
>> On Tue, 29 Aug 2006, 17:15+0200, Andre Oppermann wrote:
>>
>>> 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.
>>>
>>> Honestly I'm a bit confused myself now and have to dig up things from
>>> when I did the change. However I'm certain there was a problem and the
>>> commit fixed it in some way (not necessarily the correct way). Before
>>> the 'fix' there were some larger leaks going on.
>>
>>
>> So what's the conclusion? Perhaps it's worth to add an XXX comment in
>> meantime.
>
>
> Please give me until Thursday to resolve this issue.
>
--
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?450070CC.7070701>