netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <zajec5@gmail.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Felix Fietkau <nbd@nbd.name>, John Crispin <john@phrozen.org>,
	Jo-Philipp Wich <jo@mein.io>
Subject: Re: Regression: net/ipv6/mld running system out of memory (not a leak)
Date: Wed, 4 Mar 2020 08:44:29 +0100	[thread overview]
Message-ID: <d34a35e0-2dbe-fab8-5cf8-5c80cb5ec645@gmail.com> (raw)
In-Reply-To: <20200304064504.GY2159@dhcp-12-139.nay.redhat.com>

On 04.03.2020 07:45, Hangbin Liu wrote:
> On Tue, Mar 03, 2020 at 10:23:12AM +0100, Rafał Miłecki wrote:
>> On 03.03.2020 10:11, Hangbin Liu wrote:
>>> On Tue, Mar 03, 2020 at 05:00:35PM +0800, Hangbin Liu wrote:
>>>> On Tue, Mar 03, 2020 at 07:16:44AM +0100, Rafał Miłecki wrote:
>>>>> It appears that every interface up & down sequence results in adding a
>>>>> new ff02::2 entry to the idev->mc_tomb. Doing that over and over will
>>>>> obviously result in running out of memory at some point. That list isn't
>>>>> cleared until removing an interface.
>>>>
>>>> Thanks Rafał, this info is very useful. When we set interface up, we will
>>>> call ipv6_add_dev() and add in6addr_linklocal_allrouters to the mcast list.
>>>> But we only remove it in ipv6_mc_destroy_dev(). This make the link down save
>>>> the list and link up add a new one.
>>>>
>>>> Maybe we should remove the list in ipv6_mc_down(). like:
>>>
>>> Or maybe we just remove the list in addrconf_ifdown(), as opposite of
>>> ipv6_add_dev(), which looks more clear.
>>>
>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>> index 164c71c54b5c..4369087b8b74 100644
>>> --- a/net/ipv6/addrconf.c
>>> +++ b/net/ipv6/addrconf.c
>>> @@ -3841,6 +3841,12 @@ static int addrconf_ifdown(struct net_device *dev, int how)
>>>                   ipv6_ac_destroy_dev(idev);
>>>                   ipv6_mc_destroy_dev(idev);
>>>           } else {
>>> +               ipv6_dev_mc_dec(dev, &in6addr_interfacelocal_allnodes);
>>> +               ipv6_dev_mc_dec(dev, &in6addr_linklocal_allnodes);
>>> +
>>> +               if (idev->cnf.forwarding && (dev->flags & IFF_MULTICAST))
>>> +                       ipv6_dev_mc_dec(dev, &in6addr_linklocal_allrouters);
>>> +
>>>                   ipv6_mc_down(idev);
>>>           }
>>
>> FWIW I can confirm it fixes the problem for me!
>>
>> Only one ff02::2 entry is present when removing interface:
>>
>> [  105.686503] [ipv6_mc_destroy_dev] idev->dev->name:mon-phy0
>> [  105.692056] [ipv6_mc_down] idev->dev->name:mon-phy0
>> [  105.696957] [ipv6_mc_destroy_dev -> __mld_clear_delrec] kfree(pmc:c64fd880) ff02::2
> 
> Hi Rafał,
> 
> When review the code, I got confused. On the latest net code, we only
> add the allrouter address to multicast list in function
> 1) ipv6_add_dev(), which only called when there is no idev. But link down and
>     up would not re-create idev.
> 2) dev_forward_change(), which only be called during forward change, this
>     function will handle add/remove allrouter address correctly.

Sharp eye! You're right, I tracked (with just a pr_info) all usages of
in6addr_linklocal_allrouters and none gets triggered during my testing
routine. I'm wondering if I should start blaming my OpenWrt user space
now.


> So I still don't know how you could added the ff02::2 on same dev multi times.
> Does just do `ip link set $dev down; ip link set $dev up` reproduce your
> problem? Or did I miss something?

A bit old-fashioned with ifconfig but basically yes, that's my test:

iw phy phy0 interface add mon-phy0 type monitor
for i in $(seq 1 10); do ifconfig mon-phy0 up; ifconfig mon-phy0 down; done
iw dev mon-phy0 del

  reply	other threads:[~2020-03-04  7:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12  7:37 Regression: net/ipv6/mld running system out of memory (not a leak) Rafał Miłecki
2020-02-12  7:59 ` Eric Dumazet
2020-02-12  8:46   ` Rafał Miłecki
2020-02-12  8:24 ` Hangbin Liu
2020-02-12  8:49   ` Rafał Miłecki
2020-02-12 10:08     ` Hangbin Liu
2020-02-18  6:55       ` Rafał Miłecki
2020-02-18  8:27         ` Hangbin Liu
2020-02-18  8:08 ` Rafał Miłecki
2020-02-18  8:53   ` Hangbin Liu
2020-03-03  6:16 ` Rafał Miłecki
2020-03-03  9:00   ` Hangbin Liu
2020-03-03  9:11     ` Hangbin Liu
2020-03-03  9:23       ` Rafał Miłecki
2020-03-03  9:26         ` Hangbin Liu
2020-03-04  6:45         ` Hangbin Liu
2020-03-04  7:44           ` Rafał Miłecki [this message]
2020-03-04  9:07             ` Hangbin Liu
2020-03-04 10:07               ` Rafał Miłecki
2020-03-05  4:02                 ` Hangbin Liu
2020-03-06 11:14               ` Rafał Miłecki
2020-03-09  8:33                 ` Hangbin Liu
2020-03-09 12:31                   ` Rafał Miłecki
2020-03-10  7:09                     ` Hangbin Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d34a35e0-2dbe-fab8-5cf8-5c80cb5ec645@gmail.com \
    --to=zajec5@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jo@mein.io \
    --cc=john@phrozen.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=liuhangbin@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).