Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1489587
| From | Florian Westphal <fw@strlen.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive |
| Date | 2016-09-23 00:00 +0200 |
| Message-ID | <skkc9-3ii-1@gated-at.bofh.it> (permalink) |
| References | <sjVQu-4Lc-11@gated-at.bofh.it> <sjWWe-5EH-21@gated-at.bofh.it> <skgrU-10r-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive Fabian Frederick <fabf@skynet.be> - 2016-09-21 22:00 +0200
Re: [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive Florian Westphal <fw@strlen.de> - 2016-09-21 23:10 +0200
Re: [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive Fabian Frederick <fabf@skynet.be> - 2016-09-22 20:00 +0200
Re: [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive Florian Westphal <fw@strlen.de> - 2016-09-23 00:00 +0200
Re: [PATCH 1/1 linux-next] netfilter: conntrack: fix kmemleak false positive Fabian Frederick <fabf@skynet.be> - 2016-09-23 21:50 +0200
csiph-web