* Memory leaks in conntrack
@ 2017-09-12 23:20 Cong Wang
2017-09-13 8:05 ` Florian Westphal
0 siblings, 1 reply; 5+ messages in thread
From: Cong Wang @ 2017-09-12 23:20 UTC (permalink / raw)
To: netfilter-devel; +Cc: Linux Kernel Network Developers
Hello,
While testing my TC filter patches (so not related to conntrack), the
following memory leaks are shown up:
unreferenced object 0xffff9b19ba551228 (size 128):
comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
hex dump (first 32 bytes):
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
backtrace:
[<ffffffff9f1e1175>] create_object+0x169/0x2aa
[<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
[<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
[<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
[<ffffffff9f193c3b>] __krealloc+0x4a/0x69
[<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
[<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
[<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
[<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
[<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
[<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
[<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
[<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
[<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
[<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
[<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
unreferenced object 0xffff9b19a69b3340 (size 336):
comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
hex dump (first 32 bytes):
01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
backtrace:
[<ffffffff9f1e1175>] create_object+0x169/0x2aa
[<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
[<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
[<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
[<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
[<ffffffff9f942250>] init_conntrack+0xb2/0x36e
[<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
[<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
[<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
[<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
[<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
[<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
[<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
[<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
[<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
[<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
This seems new because I never see this before.
I don't touch chronyd in my VM, so I have no idea why it sends out UDP
packets, my guess is it is some periodical packet.
I don't think I use conntrack either, since /proc/net/ip_conntrack
does not exist.
Here are some related config of my kernel:
$ grep CONNTRACK .config
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_ZONES=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_EVENTS=y
# CONFIG_NF_CONNTRACK_TIMEOUT is not set
CONFIG_NF_CONNTRACK_TIMESTAMP=y
CONFIG_NF_CONNTRACK_AMANDA=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_H323=y
CONFIG_NF_CONNTRACK_IRC=y
CONFIG_NF_CONNTRACK_BROADCAST=y
CONFIG_NF_CONNTRACK_NETBIOS_NS=y
CONFIG_NF_CONNTRACK_SNMP=y
CONFIG_NF_CONNTRACK_PPTP=y
CONFIG_NF_CONNTRACK_SANE=y
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CONNTRACK_TFTP=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_IPV6=y
Please let me know if you need any other information.
Thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory leaks in conntrack
2017-09-12 23:20 Memory leaks in conntrack Cong Wang
@ 2017-09-13 8:05 ` Florian Westphal
2017-09-13 15:37 ` Florian Westphal
2017-09-13 16:45 ` Cong Wang
0 siblings, 2 replies; 5+ messages in thread
From: Florian Westphal @ 2017-09-13 8:05 UTC (permalink / raw)
To: Cong Wang; +Cc: netfilter-devel, Linux Kernel Network Developers
Cong Wang <xiyou.wangcong@gmail.com> wrote:
> While testing my TC filter patches (so not related to conntrack), the
> following memory leaks are shown up:
>
> unreferenced object 0xffff9b19ba551228 (size 128):
> comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
> hex dump (first 32 bytes):
> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> 00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
> backtrace:
> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
> [<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
> [<ffffffff9f193c3b>] __krealloc+0x4a/0x69
> [<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
> [<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
> unreferenced object 0xffff9b19a69b3340 (size 336):
> comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
> hex dump (first 32 bytes):
> 01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
> ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
> backtrace:
> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
> [<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
> [<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
> [<ffffffff9f942250>] init_conntrack+0xb2/0x36e
> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
> [<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
>
> I don't touch chronyd in my VM, so I have no idea why it sends out UDP
> packets, my guess is it is some periodical packet.
>
> I don't think I use conntrack either, since /proc/net/ip_conntrack
> does not exist.
You probably do, can you try "cat /proc/net/nf_conntrack" instead?
(otherwise there should be no ipv4_conntrack_local() invocation
since we would not register this hook at all).
I tried to reproduce this but so far I had no success.
If you can identify something that could give a hint when this
is happening (only once after boot, periodically, only with udp, etc)
please let us know.
(A reproducer would be even better of course ;-) )
Is this with current net tree?
Thanks!
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory leaks in conntrack
2017-09-13 8:05 ` Florian Westphal
@ 2017-09-13 15:37 ` Florian Westphal
2017-09-13 16:45 ` Cong Wang
1 sibling, 0 replies; 5+ messages in thread
From: Florian Westphal @ 2017-09-13 15:37 UTC (permalink / raw)
To: Florian Westphal
Cc: Cong Wang, netfilter-devel, Linux Kernel Network Developers
Florian Westphal <fw@strlen.de> wrote:
> Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > While testing my TC filter patches (so not related to conntrack), the
> > following memory leaks are shown up:
> >
> > unreferenced object 0xffff9b19ba551228 (size 128):
> > comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
> > hex dump (first 32 bytes):
> > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > 00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
> > backtrace:
> > [<ffffffff9f1e1175>] create_object+0x169/0x2aa
> > [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
> > [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
> > [<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
> > [<ffffffff9f193c3b>] __krealloc+0x4a/0x69
> > [<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
> > [<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
> > [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
> > [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
> > [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
> > [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
> > [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
> > [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
> > [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
> > [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
> > [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
> > unreferenced object 0xffff9b19a69b3340 (size 336):
> > comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
> > hex dump (first 32 bytes):
> > 01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
> > ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
> > backtrace:
> > [<ffffffff9f1e1175>] create_object+0x169/0x2aa
> > [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
> > [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
> > [<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
> > [<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
> > [<ffffffff9f942250>] init_conntrack+0xb2/0x36e
> > [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
> > [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
> > [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
> > [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
> > [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
> > [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
> > [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
> > [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
> > [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
> > [<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
> >
> > I don't touch chronyd in my VM, so I have no idea why it sends out UDP
> > packets, my guess is it is some periodical packet.
> >
> > I don't think I use conntrack either, since /proc/net/ip_conntrack
> > does not exist.
>
> You probably do, can you try "cat /proc/net/nf_conntrack" instead?
>
> (otherwise there should be no ipv4_conntrack_local() invocation
> since we would not register this hook at all).
>
> I tried to reproduce this but so far I had no success.
> If you can identify something that could give a hint when this
> is happening (only once after boot, periodically, only with udp, etc)
> please let us know.
FWIW i managed to obtain a similar backtrace, but in that case it was a
false positive (peeking at the address content showed it was my ssh connection
to the vm and timeout and tcp conntrackk struct fields were changing;
i.e. the nf_conn reported was still in the conntrack hash.
Why this address was reported i do not know, afaik kmemleak
does scan for addresses anywhere in the object (we use
container_of() to get back nf_conn from the hlist_node), so it
should have found the address linked via the main conntrack hash table.
Right now I don't have enough info to dig any further, sorry :-/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory leaks in conntrack
2017-09-13 8:05 ` Florian Westphal
2017-09-13 15:37 ` Florian Westphal
@ 2017-09-13 16:45 ` Cong Wang
2017-09-13 17:58 ` Cong Wang
1 sibling, 1 reply; 5+ messages in thread
From: Cong Wang @ 2017-09-13 16:45 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, Linux Kernel Network Developers
On Wed, Sep 13, 2017 at 1:05 AM, Florian Westphal <fw@strlen.de> wrote:
> Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> While testing my TC filter patches (so not related to conntrack), the
>> following memory leaks are shown up:
>>
>> unreferenced object 0xffff9b19ba551228 (size 128):
>> comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
>> hex dump (first 32 bytes):
>> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>> 00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
>> backtrace:
>> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
>> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
>> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
>> [<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
>> [<ffffffff9f193c3b>] __krealloc+0x4a/0x69
>> [<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
>> [<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
>> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
>> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
>> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
>> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
>> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
>> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
>> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
>> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
>> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
>> unreferenced object 0xffff9b19a69b3340 (size 336):
>> comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
>> hex dump (first 32 bytes):
>> 01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
>> ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
>> backtrace:
>> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
>> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
>> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
>> [<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
>> [<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
>> [<ffffffff9f942250>] init_conntrack+0xb2/0x36e
>> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
>> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
>> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
>> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
>> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
>> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
>> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
>> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
>> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
>> [<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
>>
>> I don't touch chronyd in my VM, so I have no idea why it sends out UDP
>> packets, my guess is it is some periodical packet.
>>
>> I don't think I use conntrack either, since /proc/net/ip_conntrack
>> does not exist.
>
> You probably do, can you try "cat /proc/net/nf_conntrack" instead?
>
> (otherwise there should be no ipv4_conntrack_local() invocation
> since we would not register this hook at all).
Yeah it is very weird but it is true:
[root@localhost ~]# echo scan > /sys/kernel/debug/kmemleak
[ 133.450823] kmemleak: 18 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
[root@localhost ~]# cat /proc/net/ip_conntrack
cat: /proc/net/ip_conntrack: No such file or directory
[root@localhost ~]# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff95c1e0b24040 (size 336):
...
>
> I tried to reproduce this but so far I had no success.
> If you can identify something that could give a hint when this
> is happening (only once after boot, periodically, only with udp, etc)
> please let us know.
>
> (A reproducer would be even better of course ;-) )
Actually, it is even simpler to reproduce, nothing is needed
but wait. I thought it is somewhat triggered by my tests, but
actually no. For me, just boot the VM and wait for several
seconds, memleak will show up.
(chronyd is started by systemd during boot, not me.)
>
> Is this with current net tree?
Yes, I just pulled DaveM's net tree and recompiled the kernel,
still 100% reproducible here.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory leaks in conntrack
2017-09-13 16:45 ` Cong Wang
@ 2017-09-13 17:58 ` Cong Wang
0 siblings, 0 replies; 5+ messages in thread
From: Cong Wang @ 2017-09-13 17:58 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, Linux Kernel Network Developers
On Wed, Sep 13, 2017 at 9:45 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Sep 13, 2017 at 1:05 AM, Florian Westphal <fw@strlen.de> wrote:
>> Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> While testing my TC filter patches (so not related to conntrack), the
>>> following memory leaks are shown up:
>>>
>>> unreferenced object 0xffff9b19ba551228 (size 128):
>>> comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
>>> hex dump (first 32 bytes):
>>> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>>> 00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
>>> backtrace:
>>> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
>>> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
>>> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
>>> [<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
>>> [<ffffffff9f193c3b>] __krealloc+0x4a/0x69
>>> [<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
>>> [<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
>>> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
>>> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
>>> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
>>> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
>>> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
>>> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
>>> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
>>> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
>>> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
>>> unreferenced object 0xffff9b19a69b3340 (size 336):
>>> comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
>>> hex dump (first 32 bytes):
>>> 01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
>>> ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
>>> backtrace:
>>> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
>>> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
>>> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
>>> [<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
>>> [<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
>>> [<ffffffff9f942250>] init_conntrack+0xb2/0x36e
>>> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
>>> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
>>> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
>>> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
>>> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
>>> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
>>> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
>>> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
>>> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
>>> [<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
>>>
>>> I don't touch chronyd in my VM, so I have no idea why it sends out UDP
>>> packets, my guess is it is some periodical packet.
>>>
>>> I don't think I use conntrack either, since /proc/net/ip_conntrack
>>> does not exist.
>>
>> You probably do, can you try "cat /proc/net/nf_conntrack" instead?
>>
>> (otherwise there should be no ipv4_conntrack_local() invocation
>> since we would not register this hook at all).
>
> Yeah it is very weird but it is true:
>
> [root@localhost ~]# echo scan > /sys/kernel/debug/kmemleak
> [ 133.450823] kmemleak: 18 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
> [root@localhost ~]# cat /proc/net/ip_conntrack
> cat: /proc/net/ip_conntrack: No such file or directory
> [root@localhost ~]# cat /sys/kernel/debug/kmemleak
> unreferenced object 0xffff95c1e0b24040 (size 336):
> ...
Oops, you mean nf_conntrack... Here we go:
[root@localhost ~]# cat /proc/net/nf_conntrack
ipv4 2 udp 17 116 src=192.168.124.6 dst=204.2.134.162
sport=123 dport=123 src=204.2.134.162 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 117 src=192.168.124.6 dst=45.79.187.10
sport=123 dport=123 src=45.79.187.10 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=35486 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=35486 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=52373 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=52373 [ASSURED] mark=0 zone=0 use=2
ipv4 2 unknown 2 518 src=192.168.124.6 dst=224.0.0.22 [UNREPLIED]
src=224.0.0.22 dst=192.168.124.6 mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=43242 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=43242 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 116 src=192.168.124.6 dst=96.226.123.196
sport=123 dport=123 src=96.226.123.196 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=42838 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=42838 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 117 src=192.168.124.6 dst=97.127.104.4
sport=123 dport=123 src=97.127.104.4 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-09-13 17:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-12 23:20 Memory leaks in conntrack Cong Wang
2017-09-13 8:05 ` Florian Westphal
2017-09-13 15:37 ` Florian Westphal
2017-09-13 16:45 ` Cong Wang
2017-09-13 17:58 ` Cong Wang
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.