From yar@bsd.chem.msu.ru  Tue Mar  1 06:18:34 2005
Return-Path: <yar@bsd.chem.msu.ru>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 93CC016A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  1 Mar 2005 06:18:34 +0000 (GMT)
Received: from bsd.chem.msu.ru (bsd.chem.msu.ru [195.208.208.23])
	by mx1.FreeBSD.org (Postfix) with ESMTP id C4C5943D41
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  1 Mar 2005 06:18:33 +0000 (GMT)
	(envelope-from yar@bsd.chem.msu.ru)
Received: from bsd.chem.msu.ru (localhost [127.0.0.1])
	by bsd.chem.msu.ru (8.13.1/8.13.1) with ESMTP id j216IWaR071305
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 1 Mar 2005 09:18:32 +0300 (MSK)
	(envelope-from yar@bsd.chem.msu.ru)
Received: (from yar@localhost)
	by bsd.chem.msu.ru (8.13.1/8.13.1/Submit) id j216IVQS071304;
	Tue, 1 Mar 2005 09:18:31 +0300 (MSK)
	(envelope-from yar)
Message-Id: <200503010618.j216IVQS071304@bsd.chem.msu.ru>
Date: Tue, 1 Mar 2005 09:18:31 +0300 (MSK)
From: Yar Tikhiy <yar@comp.chem.msu.su>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Destroying a network interface leaks kernel memory
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         78227
>Category:       kern
>Synopsis:       [netinet] [patch] Destroying a network interface leaks kernel memory
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bms
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 01 06:20:15 GMT 2005
>Closed-Date:    Sat Oct 07 10:44:07 GMT 2006
>Last-Modified:  Sat Oct  7 10:50:17 GMT 2006
>Originator:     Yar Tikhiy
>Release:        FreeBSD 6.0-CURRENT i386
>Organization:
MSU
>Environment:

5-STABLE, 6-CURRENT

>Description:

It was originally reported by Oleg Bulyzhin <oleg <@> rinet <.> ru>
that destroying a vlan(4) interface with an assigned IP address would
leak kernel memory.

Further investigation has shown that the problem isn't specific to
vlan(4) and affects any multicast interface.  The system just doesn't
seem to leave the "all hosts" multicast group upon dismantling an
interface.

In my case, each plumb/unplumb cycle on a vlan(4) interface leaks
1 in_multi memory block and 5 ether_multi blocks.  For lo(4) the
amounts are 1 and 2, respectively.

>How-To-Repeat:

# change lo11 to vlanXX and add vlan/vlandev to the create command to test on vlan
vmstat -m > vmstat-m.0
for n in `yes | head -1000`; do
	ifconfig lo11 create inet 1.1.1.1/24 up
	ifconfig lo11 destroy
done
vmstat -m > vmstat-m.1
diff vmstat-m.0 vmstat-m.1

>Fix:
>Release-Note:
>Audit-Trail:

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Yar Tikhiy <yar@comp.chem.msu.su>, oleg@rinet.ru
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/78227: Destroying a network interface leaks kernel memory
Date: Wed, 9 Mar 2005 18:13:15 +0300

 --vtzGhvizbBRQ85DL
 Content-Type: text/plain; charset=koi8-r
 Content-Disposition: inline
 
   This is already fixed in NetBSD a long time ago, and recently in OpenBSD.
 
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/in.c#rev1.64
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/in.c#rev1.65
 
 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/in.c#rev1.39
 
 I like OpenBSD's solution. Please look at the attached patch; it
 adds in_multi pointer into in_ifaddr, assigns it return value of
 in_addmulti() and calls in_delmulti() when removing address.
 
 P.S. I suspect we also have a memory leak when interface is joined a
 multicast group and then destroyed.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE
 
 --vtzGhvizbBRQ85DL
 Content-Type: text/plain; charset=koi8-r
 Content-Disposition: attachment; filename="kern.78227.diff"
 
 Index: in.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/netinet/in.c,v
 retrieving revision 1.81
 diff -u -r1.81 in.c
 --- in.c	7 Jan 2005 01:45:44 -0000	1.81
 +++ in.c	9 Mar 2005 15:05:32 -0000
 @@ -433,6 +433,14 @@
  		 */
  		in_ifscrub(ifp, ia);
  		/*
 +		 * Leave all hosts multicast group,
 +		 * freeing memory.
 +		 */
 +		if (ia->ia_allhosts != NULL) {
 +			in_delmulti(ia->ia_allhosts);
 +			ia->ia_allhosts = NULL;
 +		}
 +		/*
  		 * in_ifadown gets rid of all the rest of
  		 * the routes.  This is not quite the right
  		 * thing to do, but at least if we are running
 @@ -746,11 +760,11 @@
  	 * If the interface supports multicast, join the "all hosts"
  	 * multicast group on that interface.
  	 */
 -	if (ifp->if_flags & IFF_MULTICAST) {
 +	if ((ifp->if_flags & IFF_MULTICAST) && ia->ia_allhosts == NULL) {
  		struct in_addr addr;
  
  		addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP);
 -		in_addmulti(&addr, ifp);
 +		ia->ia_allhosts =  in_addmulti(&addr, ifp);
  	}
  	return (error);
  }
 Index: in_var.h
 ===================================================================
 RCS file: /home/ncvs/src/sys/netinet/in_var.h,v
 retrieving revision 1.53
 diff -u -r1.53 in_var.h
 --- in_var.h	7 Jan 2005 01:45:44 -0000	1.53
 +++ in_var.h	9 Mar 2005 15:00:40 -0000
 @@ -58,6 +58,8 @@
  	struct	sockaddr_in ia_dstaddr; /* reserve space for broadcast addr */
  #define	ia_broadaddr	ia_dstaddr
  	struct	sockaddr_in ia_sockmask; /* reserve space for general netmask */
 +	struct	in_multi *ia_allhosts;	 /* multicast address record for
 +					    the allhosts multicast group */
  };
  
  struct	in_aliasreq {
 
 --vtzGhvizbBRQ85DL--

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Brooks Davis <brooks@one-eyed-alien.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/78227: Destroying a network interface leaks kernel memory
Date: Thu, 10 Mar 2005 09:38:50 +0300

 On Wed, Mar 09, 2005 at 08:02:41AM -0800, Brooks Davis wrote:
 B> >  I like OpenBSD's solution. Please look at the attached patch; it
 B> >  adds in_multi pointer into in_ifaddr, assigns it return value of
 B> >  in_addmulti() and calls in_delmulti() when removing address.
 B> 
 B> This looks fine to me.
 B> 
 B> >  P.S. I suspect we also have a memory leak when interface is joined a
 B> >  multicast group and then destroyed.
 B> 
 B> Actually, I believe it's a panic. :(  I haven't had a chance to look at
 B> it much, but I put what I found in kern/77665.  It's pretty easy to
 B> trigger if you have a pccard/cardbus nic.
 
 Yes yes. I have looked at this PR also. In OpenBSD they have a LIST_HEAD in
 in_ifaddr for all multicast addresses. However, I see that it is LIST_INITed
 at initialization and all multicast addresses are LIST_INSERTed there, but
 I don't see where they are removed. I don't have OpenBSD box to play with and
 try to reproduce your panic.
 
 I think kern/77665 should be fixed next after this PR.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: "Yar Tikhiy" <yar@comp.chem.msu.su>
To: <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/78227: Destroying a network interface leaks kernel memory
Date: Wed, 31 Aug 2005 18:38:29 +0400

 For reference, here's the current list of PR's related to the issue of IP
 multicast and interfaces:
 
 PR kern/77665
 PR kern/78227
 PR kern/82882
 

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org,  glebius@FreeBSD.org
Cc:  
Subject: Re: kern/78227: [netinet] [patch] Destroying a network interface
 leaks kernel memory
Date: Mon, 25 Sep 2006 18:32:11 +0100

 Gleb,
 
 There is definitely an unmatched allocation here due to 224.0.0.1.
 
 Your patch looks good, but I haven't tested it. Do you plan to commit?
 
 BMS

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Bruce M Simpson <bms@incunabulum.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/78227: [netinet] [patch] Destroying a network interface leaks kernel memory
Date: Wed, 27 Sep 2006 17:37:27 +0400

 On Mon, Sep 25, 2006 at 06:32:11PM +0100, Bruce M Simpson wrote:
 B> There is definitely an unmatched allocation here due to 224.0.0.1.
 B> Your patch looks good, but I haven't tested it. Do you plan to commit?
 
 Since that time Robert has extensively rewritten the multicast stuff.
 That's why I avoided to commit my patch and decided to come back to
 that problem later.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/78227: [netinet] [patch] Destroying a network interface
 leaks kernel memory
Date: Wed, 27 Sep 2006 15:40:41 +0100

 To reproduce this bug on 7-CURRENT:
 
 0. Note memory usage before beginning:
 sandbox# vmstat -m | grep in_multi
          Type InUse MemUse HighUse Requests  Size(s)
      in_multi     4     1K       -        4  32
 
 1. Create a clonable interface e.g. a vlan.
 sandbox# ifconfig vlan0 create
 sandbox# ifconfig vlan0 vlan 1 vlandev ed0
 
 2. Bind it to netinet by configuring an IPv4 address.
 sandbox# ifconfig vlan0 10.0.0.1/24
 
 3. Note membership of 224.0.0.1:
 sandbox# netstat -g | grep vlan0
 224.0.0.1               01:00:5e:00:00:01       vlan0
 
 4. Note memory usage:
 sandbox# vmstat -m | grep in_multi
      in_multi     5     1K       -        5  32
 
 5. Unbind from netinet by deleting the address:
 sandbox# ifconfig vlan0 delete
 
 6. Note memory usage:
 sandbox# vmstat -m | grep in_multi
      in_multi     5     1K       -        5  32
 
 7. Note membership of 224.0.0.1:
 sandbox# netstat -g | grep vlan0
 224.0.0.1               01:00:5e:00:00:01       vlan0
 
 8. Destroy the interface instance:
 sandbox# ifconfig vlan0 destroy
 
 9. Note memory usage:
 sandbox# vmstat -m | grep in_multi
          Type InUse MemUse HighUse Requests  Size(s)
      in_multi     5     1K       -        5  32
 
 10. Try creating another vlan interface; note than InUse does not go down.
 
State-Changed-From-To: open->analyzed 
State-Changed-By: bms 
State-Changed-When: Wed Sep 27 15:19:23 UTC 2006 
State-Changed-Why:  
Patch looks good 


Responsible-Changed-From-To: freebsd-bugs->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Wed Sep 27 15:19:23 UTC 2006 
Responsible-Changed-Why:  
Patch looks good 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78227 

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/78227: [netinet] [patch] Destroying a network interface
 leaks kernel memory
Date: Wed, 27 Sep 2006 16:10:11 +0100

 This is a multi-part message in MIME format.
 --------------070506080009090507070609
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 This is most definitely reproducable on 7-CURRENT. Here's a test case.
 
 --------------070506080009090507070609
 Content-Type: application/x-shellscript;
  name="test-78227.sh"
 Content-Transfer-Encoding: base64
 Content-Disposition: inline;
  filename="test-78227.sh"
 
 IyEvYmluL3NoCgpzeXNjdGwgbmV0LmxpbmsuZ2VuZXJpYy5zeXN0ZW0uaWZjb3VudAoKZWNo
 bwplY2hvICJpbl9tdWx0aSB1c2FnZSBiZWZvcmUgY3JlYXRpbmcgMjU0IHZsYW4gaW50ZXJm
 YWNlczoiCnZtc3RhdCAtbSB8IGdyZXAgaW5fbXVsdGkKdm1zdGF0IC1tIHwgZ3JlcCBldGhl
 cl9tdWx0aQoKcGFyZW50PWVkMAoKZWNobwplY2hvICJjcmVhdGluZyAyNTQgdmxhbiBpbnRl
 cmZhY2VzLi4uIgpkZXZzPSIkKGpvdCAyNTQgMSkiCmZvciBkZXYgaW4gJGRldnMgOyBkbwoJ
 aWZjb25maWcgdmxhbiRkZXYgY3JlYXRlIDI+JjEgPi9kZXYvbnVsbAoJaWZjb25maWcgdmxh
 biRkZXYgdmxhbiAkZGV2IHZsYW5kZXYgJHBhcmVudCAyPiYxID4vZGV2L251bGwKCWlmY29u
 ZmlnIHZsYW4kZGV2IDE3Mi4xNi4wLiRkZXYvMzIgMj4mMSA+L2Rldi9udWxsCgkjc3lzY3Rs
 IG5ldC5saW5rLmdlbmVyaWMuc3lzdGVtLmlmY291bnQKZG9uZQoKZWNobwplY2hvICJkZXN0
 cm95aW5nIDI1NCB2bGFuIGludGVyZmFjZXMuLi4iCmRldnM9IiQoam90IDI1NCAxKSIKZm9y
 IGRldiBpbiAkZGV2cyA7IGRvCgkjc2V0IC14CglpZmNvbmZpZyB2bGFuJGRldiBkZWxldGUg
 Mj4mMSA+L2Rldi9udWxsCglpZmNvbmZpZyB2bGFuJGRldiBkZXN0cm95IDI+JjEgPi9kZXYv
 bnVsbAoJI3N5c2N0bCBuZXQubGluay5nZW5lcmljLnN5c3RlbS5pZmNvdW50CmRvbmUKCmVj
 aG8KZWNobyAiaW5fbXVsdGkgdXNhZ2UgYWZ0ZXIgY3JlYXRpbmcgMjU0IHZsYW4gaW50ZXJm
 YWNlczoiCnZtc3RhdCAtbSB8IGdyZXAgaW5fbXVsdGkKdm1zdGF0IC1tIHwgZ3JlcCBldGhl
 cl9tdWx0aQoKZWNobyAibmV0c3RhdCAtZyB8IHdjIC1sOiIKbmV0c3RhdCAtZyB8IHdjIC1s
 CgpzeXNjdGwgbmV0LmxpbmsuZ2VuZXJpYy5zeXN0ZW0uaWZjb3VudAo=
 --------------070506080009090507070609--

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/78227: [netinet] [patch] Destroying a network interface
 leaks kernel memory
Date: Wed, 27 Sep 2006 18:36:17 +0100

 The fix is not right -- we still leak memory for non-224.0.0.1 groups on 
 interface detach.
 It looks like this bug may have been introduced inadvertently around rev 
 1.20 of in.c.

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/78227: [netinet] [patch] Destroying a network interface
 leaks kernel memory
Date: Wed, 27 Sep 2006 19:40:43 +0100

 This is a multi-part message in MIME format.
 --------------050609080303010800000706
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 A more correct fix is attached; patch against 7-CURRENT in p4.
 This is not 100% correct -- strictly speaking we should track 
 joins/leaves on a per-in_ifaddr basis, but this was broken around rev 1.20.
 It will however free the memory which would be otherwise leaked when 
 netinet detaches from the ifnet, and is modeled roughly on what our IPv6 
 implementation does.
 
 --------------050609080303010800000706
 Content-Type: text/x-patch;
  name="inmleak.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="inmleak.diff"
 
 ==== //depot/user/bms/nethead/sys/netinet/in.c#1 - /home/bms/fp4/nethead/sys/netinet/in.c ====
 --- /tmp/tmp.24071.0	Wed Sep 27 19:38:50 2006
 +++ /home/bms/fp4/nethead/sys/netinet/in.c	Wed Sep 27 19:22:49 2006
 @@ -1025,13 +1025,23 @@
  in_delmulti(inm)
  	register struct in_multi *inm;
  {
 -	struct ifmultiaddr *ifma;
 -	struct in_multi my_inm;
  	struct ifnet *ifp;
  
  	ifp = inm->inm_ifp;
  	IFF_LOCKGIANT(ifp);
  	IN_MULTI_LOCK();
 +	in_delmulti_locked(inm);
 +	IN_MULTI_UNLOCK();
 +	IFF_UNLOCKGIANT(ifp);
 +}
 +
 +void
 +in_delmulti_locked(inm)
 +	register struct in_multi *inm;
 +{
 +	struct ifmultiaddr *ifma;
 +	struct in_multi my_inm;
 +
  	ifma = inm->inm_ifma;
  	my_inm.inm_ifp = NULL ; /* don't send the leave msg */
  	if (ifma->ifma_refcount == 1) {
 @@ -1050,6 +1060,24 @@
  	if_delmulti(ifma->ifma_ifp, ifma->ifma_addr);
  	if (my_inm.inm_ifp != NULL)
  		igmp_leavegroup(&my_inm);
 +}
 +
 +/*
 + * Delete all multicast address records associated with the ifp.
 + */
 +void
 +in_delmulti_ifp(ifp)
 +	register struct ifnet *ifp;
 +{
 +	struct in_multi *inm;
 +	struct in_multi *oinm;
 +
 +	IFF_LOCKGIANT(ifp);
 +	IN_MULTI_LOCK();
 +	LIST_FOREACH_SAFE(inm, &in_multihead, inm_link, oinm) {
 +		if (inm->inm_ifp == ifp)
 +			in_delmulti_locked(inm);
 +	}
  	IN_MULTI_UNLOCK();
  	IFF_UNLOCKGIANT(ifp);
  }
 @@ -1064,4 +1092,5 @@
  
  	in_pcbpurgeif0(&ripcbinfo, ifp);
  	in_pcbpurgeif0(&udbinfo, ifp);
 +	in_delmulti_ifp(ifp);
  }
 ==== //depot/user/bms/nethead/sys/netinet/in_var.h#4 - /home/bms/fp4/nethead/sys/netinet/in_var.h ====
 --- /tmp/tmp.24071.1	Wed Sep 27 19:38:50 2006
 +++ /home/bms/fp4/nethead/sys/netinet/in_var.h	Wed Sep 27 18:44:14 2006
 @@ -247,6 +247,8 @@
  struct	route;
  struct	in_multi *in_addmulti(struct in_addr *, struct ifnet *);
  void	in_delmulti(struct in_multi *);
 +void	in_delmulti_locked(struct in_multi *);
 +void	in_delmulti_ifp(struct ifnet *ifp);
  int	in_control(struct socket *, u_long, caddr_t, struct ifnet *,
  	    struct thread *);
  void	in_rtqdrain(void);
 
 --------------050609080303010800000706--

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/78227: [netinet] [patch] Destroying a network interface
 leaks kernel memory
Date: Thu, 28 Sep 2006 10:31:52 +0100

 Check this out.
 
 Our multicast membership granularity is such that we only send IGMP 
 advertisements from the primary IPv4 address on an interface. From 
 reading the code it looks like things developed this way due to 
 wollman's rewrite of multicast memberships around rev 1.20 of in.c. The 
 reason for this was probably due to the support for IPv4 aliases at the 
 time being bug-ridden and immature (this I recall from the 2.x/3.x 
 release lifetime).
 
 This can be demonstrated by running FreeBSD 7-CURRENT in QEMU and doing 
 a few experiments.
 
 sandbox# ifconfig
 ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 192.168.253.250 netmask 0xffffff00 broadcast 192.168.253.255
         ether 00:11:22:33:44:55
         media: Ethernet 10baseT/UTP <full-duplex>
 ed1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
         ether 00:11:22:33:44:66
         media: Ethernet 10baseT/UTP <full-duplex>
 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
         inet 127.0.0.1 netmask 0xff000000
 sandbox# ifconfig ed0 alias 10.0.0.1/24
 sandbox# ifconfig ed0 alias 10.0.1.1/24
 sandbox# mtest
 multicast membership test program; enter ? for list of commands
 j 224.0.0.8 10.0.0.1
 group joined
 j 224.0.0.8 10.0.1.1
 mtest: can't join group: Address already in use
 j 224.0.0.8 10.0.0.1
 mtest: can't join group: Address already in use
 l 224.0.0.8 10.0.1.1
 group left
 q
 sandbox# netstat -g
 
 Virtual Interface Table is empty
 
 Multicast Routing Table is empty
 
 No IPv6 multicast routing compiled into this system.
 IPv4/IPv6 Multicast Group Memberships
 Group                   Gateway                 Netif
 224.0.0.1               01:00:5e:00:00:01       ed0
 224.0.0.1               <none>                  lo0
 
 While you're doing this, tcpdump on the tap interface connected to QEMU:
 
 empiric:~ % tcpdump -i tap0 -n -v igmp
 tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 96 
 bytes
 10:16:00.144008 IP (tos 0x0, ttl   1, id 4406, offset 0, flags [none], 
 proto: IGMP (2), length: 32, options ( RA (148) len 4 )) 192.168.253.250 
  > 224.0.0.8: igmp v2 report 224.0.0.8
 10:16:08.789443 IP (tos 0x0, ttl   1, id 4407, offset 0, flags [none], 
 proto: IGMP (2), length: 32, options ( RA (148) len 4 )) 192.168.253.250 
  > 224.0.0.8: igmp v2 report 224.0.0.8
 10:25:19.590191 IP (tos 0x0, ttl   1, id 4443, offset 0, flags [none], 
 proto: IGMP (2), length: 32, options ( RA (148) len 4 )) 192.168.253.250 
  > 224.0.0.2: igmp leave 224.0.0.8
 
 Two points spring to mind:
 1. IGMP traffic is always sent from the primary in_ifaddr on the ifnet.
 2. We sent the join twice. If I join 224.0.0.8 from the primary 
 in_ifaddr itself, I see only 1 IGMP report for the join.
 
 There may well be other IGMP holes.
 
 With this in mind I'd like to commit the fix for the memory leak as it's 
 clear we're not managing IPv4 multicast group memberships on a 
 per-address basis at this time.
 
 BMS
 
State-Changed-From-To: analyzed->patched 
State-Changed-By: bms 
State-Changed-When: Thu Sep 28 10:04:42 UTC 2006 
State-Changed-Why:  
Fix committed on HEAD 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78227 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/78227: commit references a PR
Date: Thu, 28 Sep 2006 10:04:26 +0000 (UTC)

 bms         2006-09-28 10:04:08 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/netinet          in.c in_var.h 
   Log:
   The IPv4 code should clean up multicast group state when an interface
   goes away. Without this change, it leaks in_multi (and often ether_multi
   state) if many clonable interfaces are created and destroyed in quick
   succession.
   
   The concept of this fix is borrowed from KAME. Detailed information about
   this behaviour, as well as test cases, are available in the PR.
   
   PR:             kern/78227
   MFC after:      1 week
   
   Revision  Changes    Path
   1.94      +31 -2     src/sys/netinet/in.c
   1.59      +2 -0      src/sys/netinet/in_var.h
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: bms 
State-Changed-When: Sat Oct 7 10:43:55 UTC 2006 
State-Changed-Why:  
Committed, thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78227 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/78227: commit references a PR
Date: Sat,  7 Oct 2006 10:43:56 +0000 (UTC)

 bms         2006-10-07 10:43:41 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sys/netinet          in.c in_var.h 
   Log:
   MFC: The IPv4 code should clean up multicast group state when an interface
   goes away. Without this change, it leaks in_multi (and often ether_multi
   state) if many clonable interfaces are created and destroyed in quick
   succession.
   
   The concept of this fix is borrowed from KAME. Detailed information about
   this behaviour, as well as test cases, are available in the PR.
   
   PR:             kern/78227
   Approved by:    re (rwatson)
   Revs:           1.94 src/sys/netinet/in.c
   Revs:           1.59 src/sys/netinet/in_var.h
   
   Revision  Changes    Path
   1.85.2.7  +31 -2     src/sys/netinet/in.c
   1.53.2.4  +2 -0      src/sys/netinet/in_var.h
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
>Unformatted:
