[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACna6rzgH0Ltgib+mmDNLMQE5qmU2xBYUFBJDCswvyC1bnonjg@mail.gmail.com>
Date: Tue, 18 Feb 2020 09:08:54 +0100
From: Rafał Miłecki <zajec5@...il.com>
To: Network Development <netdev@...r.kernel.org>,
Hangbin Liu <liuhangbin@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Cc: 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 Wed, 12 Feb 2020 at 08:37, Rafał Miłecki <zajec5@...il.com> wrote:
> I run Linux based OpenWrt distribution on home wireless devices (ARM
> routers and access points with brcmfmac wireless driver). I noticed
> that using wireless monitor mode interface results in my devices (128
> MiB RAM) running out of memory in about 2 days. This is NOT a memory
> leak as putting wireless down brings back all the memory.
>
> Interestingly this memory drain requires at least one of:
> net.ipv6.conf.default.forwarding=1
> net.ipv6.conf.all.forwarding=1
> to be set. OpenWrt happens to use both by default.
>
> This regression was introduced by the commit 1666d49e1d41 ("mld: do
> not remove mld souce list info when set link down") - first appeared
> in 4.10 and then backported. This bug exists in 4.9.14 and 4.14.169.
> Reverting that commit from 4.9.14 and 4.14.169 /fixes/ the problem.
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?
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?
Powered by blists - more mailing lists