From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org,
Catalin Marinas <catalin.marinas@arm.com>
Cc: Jinho Ju <wnwlsgh98@gmail.com>,
netdev@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Fwd: Fwd: memory leak in batadv_iv_ogm_aggregate_new
Date: Thu, 21 Dec 2023 09:36:38 +0100 [thread overview]
Message-ID: <3458658.QJadu78ljV@ripper> (raw)
In-Reply-To: <CAF0rt231R2FW9NP_f5HOoSQsCaK3XSZfZxbhTkKvqM0n7orbOg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
On Thursday, 21 December 2023 06:52:01 CET Jinho Ju wrote:
> Resending to everyone on the mailing list as per previous mail, adding some
> things that were missing.
>
> Regarding the cause of the L2-related crash being detected by syzkaller,
What crash? I can't see it in your mail [1]
> I
> can't say for sure - what I can say for sure at this point is that a
> memleak occurring in L2 was detected by my personal syzkaller.
Nothing tells you that the actual leak happened in layer 2. You only know that
packets were generated in batman-adv and mac80211_hwsim. But nothing tells you
what actually lost track of the skbuff (if that even happens).
> Moving away from syzkaller for a moment and shifting the focus to memleak,
> we have to assume that the conditions for this to occur are that they
> reference the same network stack and are found in modules in L2,
What do you mean with "reference the same network stack"?
And no, nothing tells you that the culprit is actually something related to
network layer 2.
> but it
> seems that when batman-adv is freed and returned while accessing and
> processing a skb in veth (L3),
veth is layer 2.
> memleak occurs because it is trying to
> reference the same skb, the veth freed skb.
This doesn't make a lot of sense. batman-adv is not referencing the skb
anymore after it was submitted to the underlying device. And if it would
reference anything then it would not be a memleak.
There are a lot of possibilities:
* kmemleak cannot not handling transient queue state correctly while the
namespace is destroyed (because it doesn't have a consistent memory state
while it scans)
* removing of the network namespace (used by the reproducers) might leak skbs
which are currently passed around between the queues
* there is an actual memory leak somewhere while the queued packets are processed
* ...
The first two option seem plausible to me because you can see "memory leaks"
in for other things which regularly (and often) transmit packets in this
namespace. In you log, this would hwsim which transmits beacons regularly (and
often).
I would guess that you see something similar when you use pktgen.
It would now be interesting if you still see the memory leak if you mark all
unfreed objects as grey and redo the scan:
echo clear > /sys/kernel/debug/kmemleak
echo scan > /sys/kernel/debug/kmemleak
If you would still see it then we could rule out the first option. If not,
then it is a false positive.
Kind regards,
Sven
[1] https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/thread/GLS6TCIPHIMWF2G6PVDEEK6UDVFB6UD2/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2023-12-21 8:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAF0rt23md=LtOu5_u4zTvZbE-cDwoJOvg7NRCqX-P=ZuQbidAA@mail.gmail.com>
2023-12-19 7:30 ` Fwd: memory leak in batadv_iv_ogm_aggregate_new Jinho Ju
[not found] ` <2788364.BEx9A2HvPv@sven-l14>
[not found] ` <CAF0rt20CDXotBSY=wrW3oWQOQmmpDmtUpP9UaL4QK7hnuDt_0Q@mail.gmail.com>
2023-12-21 6:10 ` Fwd: " Jinho Ju
2023-12-21 8:36 ` Sven Eckelmann [this message]
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=3458658.QJadu78ljV@ripper \
--to=sven@narfation.org \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=catalin.marinas@arm.com \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=wnwlsgh98@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).