From: Florian Westphal <fw@strlen.de>
To: Fabian Frederick <fabf@skynet.be>
Cc: Florian Westphal <fw@strlen.de>,
Pablo Neira Ayuso <pablo@netfilter.org>,
linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive
Date: Thu, 22 Sep 2016 23:56:15 +0200 [thread overview]
Message-ID: <20160922215615.GA18577@breakpoint.cc> (raw)
In-Reply-To: <49958525.49207.1474566957624.open-xchange@webmail.nmp.proximus.be>
Fabian Frederick <fabf@skynet.be> wrote:
> Hello Florian,
>
> First problem is solved: table gets cleared 3 minutes earlier
> but I still have kmemleak before running the following:
>
> echo scan > /sys/kernel/debug/kmemleak
> cat /sys/kernel/debug/kmemleak
> Nothing
> echo scan > /sys/kernel/debug/kmemleak
> cat /sys/kernel/debug/kmemleak
> -> rsyslogd
>
> I talked about false positive because everything is cleared later.
Hmm, I fear this is a real bug and not false positive.
Should be possible to confirm this via slabinfo:
grep nf_conntrack /proc/slabinfo
The active objects should match the conntrack count.
(conntrack -C, or wc -l < /proc/....).
> > > unreferenced object 0xffff88003b0e6600 (size 248):
> > > comm "rsyslogd", pid 1595, jiffies 4294741312 (age 7.343s)
> > > ...
> > > backtrace:
> > > [] kmemleak_alloc+0x23/0x40
> > > [] kmem_cache_alloc+0xd9/0x180
> > > [] __nf_conntrack_alloc.isra.50+0x48/0x170
> > > [] nf_conntrack_in+0x3a2/0x5f0
> > > [] ipv4_conntrack_local+0x40/0x50
> > > [] nf_iterate+0x5d/0x70
> > > [] nf_hook_slow+0x5f/0xb0
> > > [] __ip_local_out+0xad/0xe0
> > > [] ip_local_out+0x17/0x40
> > > [] ip_send_skb+0x14/0x40
> > > [] udp_send_skb+0x91/0x260
> > > [] udp_sendmsg+0x2f5/0x950
> > > [] inet_sendmsg+0x60/0x90
> > > [] sock_sendmsg+0x33/0x40
> > > [] SYSC_sendto+0xee/0x160
> > > [] SyS_sendto+0x9/0x10
Hmm, so we leak when allocating conntrack for outgoing packet.
Do you do any filtering (DROP) in output/postrouting?
> > > (248 bytes being an nf_conn structure)
> > >
> > > Those structures being cleared in gc_worker() later on we can't talk
> > > about unreferenced object so this patch uses kmemleak_not_leak() to
> > > prevent those warnings.
> >
> > If thats the case, why is kmemleak complaining? Are you sure this
> > is a false positive?
Looks like a real bug to me, but I don't see anything obvious so far.
I'll look at this again tomorrow.
next prev parent reply other threads:[~2016-09-22 21:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 19:49 [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive Fabian Frederick
2016-09-21 21:02 ` Florian Westphal
2016-09-22 17:55 ` Fabian Frederick
2016-09-22 21:56 ` Florian Westphal [this message]
2016-09-23 19:40 ` Fabian Frederick
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=20160922215615.GA18577@breakpoint.cc \
--to=fw@strlen.de \
--cc=edumazet@google.com \
--cc=fabf@skynet.be \
--cc=linux-kernel@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.