Subject: Re: if_detach
To: Jason Thorpe <>
From: None <>
List: tech-net
Date: 02/02/2000 14:45:06
> > 	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?

	in6_purgeaddr() calls in6_savemkludge().  when the last interface
	address is removed by in6_purgeaddr(), the list of joined multicast
	group will be attached into in6_mk.  when if_detach() removes ifnet
	from if_list, I think if_detach should notify IPv6 part and ask
	removal of kludge entry (otherwise ifnet * will be kept there).

	i think the code does the thing right.  the missing piece is
	removal of kludge entry when ifnet goes invisible by if_detach
	(I think kludge entry should go away - am I correct?)

> > 	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...

	I think there needs to be more LIST_REMOVE(inm, inm_list) in
	sys/netinet/in.c, specifically when interface address is removed.
	(otherwise multicast group info will become orphan)
	We can just copy kludge entry code from IPv6 part.