On Wed, 02 Feb 2000 14:10:37 +0900 
 itojun@iijlab.net wrote:

 > >If you build your kernel with IFAREF_DEBUG, you'll get lots of messages
 > >on your console for where references are added and deleted, and when
 > >the ifaddr struct is actually freed.
 > 
 > 	Hmm, I see...
 > 
 > 	For IPv6, we need to listen to certain multicast group for every
 > 	interface, ff02::1, even if there's no listeners.  Since multicast
 > 	group information is attached to in6_ifaddr, it gets tricky to handle
 > 	when there's no IPv6 address attached to an interface.
 > 	in6_savemkludge() and in6_restoremkludge() address this issue, by
 > 	- keeping multicast group information into separate list when
 > 	  all IPv6 address on interface is gone,
 > 	- and recover it when IPv6 address comes back.
 > 	with latest ifmcstat(8) you can look at kludge entry.
 > 	Since kludge entry contains pointer to struct ifnet, the reference
 > 	cound will not become 0.  I think we'd need some call from if_detach()
 > 	(or PRU_PURGEIF??) to clean kludge entries up, before removing struct
 > 	ifnet.

Right, I thought I dealt with the savemkludge in in6_purgeaddr().  Maybe
I missed something?

 > 	For IPv4, the issue is not addressed.  if you remove interface
 > 	address while someone is listening to IPv6 multicast group,
 > 	multicast group information listed in ia->ia_multiaddrs will become
 > 	dangling pointer (memory leak).  We need to fix it before we tackle
 > 	if_detach.

Ah, this shouldn't be that hard to handle... Although, for IPv6 (and
for IPv6, really), I just cloned the code that was part of SIOCDIFADDR,
actually, moved that code to another function ({in,in6}_purgeaddr()).

Didn't IPv4 already deal with the multicast addresses in that case
already?  I'm guessing it did...

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>