Re: Regression: net/ipv6/mld running system out of memory (not a leak)

Hi Rafał,
On Fri, Mar 06, 2020 at 12:14:08PM +0100, Rafał Miłecki wrote:

********************
 WITHOUT YOUR PATCH
********************

The problem we're dealing with seems to be specific to non-Ethernen
devices. For ARPHRD_IEEE80211_RADIOTAP:
1. Multicast addresses get added normally - as for any Ethernet device
2. addrconf_dev_config() returns without calling addrconf_add_dev()

That means wireless monitor interface gets mcast addresses added but
not removed (like it happens for Ethernet devices).
#
# mon-phy0 (ARPHRD_IEEE80211_RADIOTAP) ***
#

addrconf_notify(NETDEV_REGISTER)
	ipv6_add_dev
		ipv6_dev_mc_inc(ff01::1)
		ipv6_dev_mc_inc(ff02::1)
		ipv6_dev_mc_inc(ff02::2)

addrconf_notify(NETDEV_UP)
	addrconf_dev_config
		/* Alas, we support only Ethernet autoconfiguration. */
		return;

addrconf_notify(NETDEV_DOWN)
	addrconf_ifdown
		ipv6_mc_down
			igmp6_group_dropped(ff02::2)
				igmp6_leave_group(ff02::2)
					mld_add_delrec(ff02::2)
			igmp6_group_dropped(ff02::1)
			igmp6_group_dropped(ff01::1)

I'm very appreciate for your analyze. This makes me know why this issue
happens and why I couldn't reproduce it.

Yes, with ARPHRD_IEEE80211_RADIOTAP, we called mld_add_delrec() every time
when ipv6_mc_down(), but we never called mld_del_delrec() as ipv6_mc_up() was
not called. This makes the idev->mc_tomb bigger and bigger.

*****************
 WITH YOUR PATCH
*****************

Things work OK - with your changes all calls like:
ipv6_dev_mc_inc(ff01::1)
ipv6_dev_mc_inc(ff02::1)
ipv6_dev_mc_inc(ff02::2)
are now part of ipv6_mc_up() which gets never called for the
ARPHRD_IEEE80211_RADIOTAP.

I got one more question though:

Should we really call ipv6_mc_down() for ARPHRD_IEEE80211_RADIOTAP?

We don't call ipv6_mc_up() so maybe ipv6_mc_down() should be avoided
too? It seems like asking for more problems in the future. Even now

Yes, for me there are actually two questions.

1. Should we avoid call ipv6_mc_down() as we don't call ipv6_mc_up() for
non-Ethernen dev. I think the answer is yes, we could. But on the
other hand, it seems IPv4 doesn't check the dev type and calls ip_mc_up()
directly in inetdev_event() NETDEV_UP.

2. Should we move ipv6_dev_mc_inc() from ipv6_add_dev() to ipv6_mc_up()?
I don't know yet, this dependents on whether we could add multicast address
on non-Ethernen dev.

we call ipv6_mc_leave_localaddr() without ipv6_mc_join_localaddr()
called first which seems unintuitive.

This doesn't matter much yet. As we will check if we have the address
in __ipv6_dev_mc_dec(), if not, we just return. But yes, form logic, this
looks asymmetric.

Thanks
Hangbin