ipv6 multicast refcnt panic

[Bruce M. Simpson]

Andrew Thompson wrote:
> I have come across this panic which appears to be from incorrect
> refcounting on the inet6 multicast code.
>   

I can reproduce this panic, however I don't entirely understand what's 
going on. When the same IPv6 unicast address is configured twice on the 
edsc0 interface, the ifmcstat(8) utility reports that the refcnt for two 
IPv6 multicast addresses changed. I do not understand why the duplicate 
unicast address isn't rejected, or why groups are being joined twice for 
the same address.

I strongly suspect this is a bug in KAME the kind of which existed in 
netinet (whereby the 224.0.0.1 address was being joined more than once 
per ifnet) which the refcounting change has exposed as a panic, a very 
brief look at the ifaddr code in netinet6 suggests this is the case.

Before second address assignment:

edsc0:
        inet6 f00f::1
                group ff01::1%edsc0 refcnt 1
                        mcast-macaddr 33:33:00:00:00:01 refcnt 1
                group ff02::2:f23c:3567%edsc0 refcnt 1
                        mcast-macaddr 33:33:f2:3c:35:67 refcnt 1
                group ff02::1%edsc0 refcnt 1
                        mcast-macaddr 33:33:00:00:00:01 refcnt 1
                group ff02::1:ff00:1%edsc0 refcnt 1
                        mcast-macaddr 33:33:ff:00:00:01 refcnt 1

After second address assignment:

edsc0:
        inet6 f00f::1
                group ff02::1:ff00:1%edsc0 refcnt 1
                        mcast-macaddr 33:33:ff:00:00:01 refcnt 1
                group ff01::1%edsc0 refcnt 2
                        mcast-macaddr 33:33:00:00:00:01 refcnt 1
                group ff02::2:f23c:3567%edsc0 refcnt 2
                        mcast-macaddr 33:33:f2:3c:35:67 refcnt 1
                group ff02::1%edsc0 refcnt 2
                        mcast-macaddr 33:33:00:00:00:01 refcnt 1

The order of the addresses in the list has flipped around, which makes 
visual comparison that much more difficult. Flipping those around to the 
same order as the first sample yields:

edsc0:
        inet6 f00f::1
                group ff01::1%edsc0 refcnt 2
                        mcast-macaddr 33:33:00:00:00:01 refcnt 1
                group ff02::2:f23c:3567%edsc0 refcnt 2
                        mcast-macaddr 33:33:f2:3c:35:67 refcnt 1
                group ff02::1%edsc0 refcnt 2
                        mcast-macaddr 33:33:00:00:00:01 refcnt 1
                group ff02::1:ff00:1%edsc0 refcnt 1
                        mcast-macaddr 33:33:ff:00:00:01 refcnt 1

So we can be sure the addresses themselves haven't changed, but the 
refcount on the IPv6 multicast entries has gone up by 1. The refcount is 
no longer proxied to the ifnet-level ifma object since the code was changed.

I don't entirely understand the relationship between the protocol-level 
multicast addresses and the unicast address in netinet6, or why 
attempting to configure the same unicast address on the same interface 
more than once wasn't rejected with an error.

As far as I can tell the code is correct for the single address case. 
I've attached a patch which makes the netinet6 detach path more like the 
netinet one, though this isn't going to make a great deal of difference 
apart from code style; the net code already calls in6_ifdetach() in the 
right order.

We can weaken the error checking in if_delmulti() to get an operational 
kernel, but this kind of defeats the point of doing the error checking 
(which is there to expose such problems). When reporting problems with 
the networking code it is helpful to use ifmcstat, INVARIANTS, and the 
DIAGNOSTIC kernel option as I tend to add code to catch cases like this.

Regards,
BMS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: in6detach.diff
Type: text/x-patch
Size: 1700 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20070412/63040303/in6detach.bin