Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Apr 2007 13:53:56 +0400
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        Bruce M Simpson <bms@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/contrib/pf/net if_pfsync.c
Message-ID:  <20070423095356.GB2742@FreeBSD.org>
In-Reply-To: <200704140101.l3E11kum000736@repoman.freebsd.org>
References:  <200704140101.l3E11kum000736@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 14, 2007 at 01:01:46AM +0000, Bruce M Simpson wrote:
B> bms         2007-04-14 01:01:46 UTC
B> 
B>   FreeBSD src repository
B> 
B>   Modified files:
B>     sys/contrib/pf/net   if_pfsync.c 
B>   Log:
B>   In member interface detach event handler, do not attempt to free state
B>   which has already been freed by in_ifdetach(). With this cumulative change,
B>   the removal of a member interface will not cause a panic in pfsync(4).
B>   
B>   Requested by:   yar
B>   PR:             86848

Sorry for late reply on this commit, I've had email problems.

Bruce, I still think that freeing multicast memberships in the
in_ifdetach() was a bad design idea. Memory should be allocated and
freed by the same module, otherwise we've got a messy architecture.

AFAIR, you have made this change to plug a memory leak. We were
leaking multicast membership added by generic IP layer (all hosts
address?), if my memory serves me well. You should have fixed this
particular leak. Adding the major sweeper of all memberships on the
interface you have plugged this particular leak, but have broken
CARP, pfsync and any other subsystem that was cleaning memory after
itself (unlike generic IP layer does).

I think that we should plug the leak correctly and remove the
in_purgemaddrs().

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE



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