Subject: Re: if_detach
To: Jason Thorpe <email@example.com>
From: None <firstname.lastname@example.org>
Date: 02/02/2000 14:10:37
> > >This mostly works ... i.e. works for my USB Ethernet, except for a dangling
> > >ifaddr reference left by the IPv6 code; have not yet tracked this down.
> > in which part do you suspect them left? i'll try to look at it.
>What I've seen is that a cloning route to the link-local-multicast
>for the address that's being detached isn't going away, and that
>would be what's holding onto the reference, I'm guessing.
>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
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
I'm compiling the latest kernel and will do some tests.
% ifconfig sm1 (all IPv6 addresses are removed)
sm1: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet 10baseT
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
(on kludge entry for sm1)
enaddr 00:00:86:05:80:fa multicnt 2
01:00:5e:00:00:01 -- 01:00:5e:00:00:01 20
33:33:00:00:00:01 -- 33:33:00:00:00:01 1