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>