[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200218085309.GT2159@dhcp-12-139.nay.redhat.com>
Date: Tue, 18 Feb 2020 16:53:09 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: Rafał Miłecki <zajec5@...il.com>
Cc: Network Development <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Felix Fietkau <nbd@....name>, John Crispin <john@...ozen.org>,
Jo-Philipp Wich <jo@...n.io>
Subject: Re: Regression: net/ipv6/mld running system out of memory (not a
leak)
On Tue, Feb 18, 2020 at 09:08:54AM +0100, Rafał Miłecki wrote:
>
> Thinking about meaning of that commit ("do not remove mld souce list
> info when set link down") made me realize one more thing.
>
> My app accessing monitor mode brings it up and down repeatedly:
> while (1) {
> ifconfig X up (ifr_flags |= IFF_UP | IFF_RUNNING)
> select(...)
> recv(...)
> ifconfig X down (ifr_flags &= ~(IFF_UP | IFF_RUNNING))
> sleep(...)
> }
>
> So maybe that bug running device out of memory was there since ever?
> Maybe before 1666d49e1d41 ("mld: do not remove mld souce list info
> when set link down") I just didn't notice it as every "ifconfig X
> down" was flushing list. Flushing it every few seconds didn't let list
> grow too big and eat all my memory?
Maybe. before that patch we will remove all the list when link down.
After that we will store the list and restore it back when link up.
>
> I'm going to test some old kernel now using monitor mode all time,
> without putting its interface down. Is there some of debugging
> mld/ipv6 kernel lists to see if there are indeed growing huge?
I will just try test with link up/down(with forwarding enabled) and see
if I can reproduce.
Thanks
Hangbin
Powered by blists - more mailing lists