Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192):
From: Yonghong Song
Date: Mon Feb 12 2018 - 12:02:07 EST
On 2/12/18 7:55 AM, Alexei Starovoitov wrote:
On Mon, Feb 12, 2018 at 09:28:33AM +0100, Daniel Borkmann wrote:
On 02/12/2018 06:47 AM, Yonghong Song wrote:
On 2/11/18 11:18 AM, Mathieu Malaterre wrote:
On Sun, Feb 11, 2018 at 5:54 PM, Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
On Sun, Feb 11, 2018 at 7:24 AM, Mathieu Malaterre <malat@xxxxxxxxxx> wrote:
Alexei,
Could you please comment on why I am seeing those memleaks being
reported on my ppc32 system ? Should they be marked as false positive
?
System is Mac Mini G4, git/master (4.15.0+), ppc.
Thanks for your time
$ dmesg
...
[ 1281.504173] kmemleak: 36 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
Where:
# cat /sys/kernel/debug/kmemleak
unreferenced object 0xdee25000 (size 192):
ÂÂ comm "systemd", pid 1, jiffies 4294894348 (age 1438.580s)
ÂÂ hex dump (first 32 bytes):
 c0 56 2f 88 00 00 00 00 00 00 00 0b 00 00 00 0c .V/.............
ÂÂÂÂ 00 00 00 08 00 00 00 01 00 00 00 01 00 00 00 01Â ................
ÂÂ backtrace:
ÂÂÂÂ [<6c69baf5>] trie_alloc+0xb0/0x150
ÂÂÂÂ [<fa093284>] SyS_bpf+0x288/0x1458
ÂÂÂÂ [<82182f53>] ret_from_syscall+0x0/0x38
unreferenced object 0xdee25900 (size 192):
ÂÂ comm "systemd", pid 1, jiffies 4294894540 (age 1437.812s)
ÂÂ hex dump (first 32 bytes):
ÂÂÂÂ c0 56 2f 88 00 00 00 00 00 00 00 0b 00 00 00 08Â .V/.............
ÂÂÂÂ 00 00 00 08 00 00 00 01 00 00 00 01 00 00 00 01Â ................
ÂÂ backtrace:
ÂÂÂÂ [<6c69baf5>] trie_alloc+0xb0/0x150
ÂÂÂÂ [<fa093284>] SyS_bpf+0x288/0x1458
ÂÂÂÂ [<82182f53>] ret_from_syscall+0x0/0x38
hmm. looks real. Is there a reproducer?
Yonghong, lpm map not cleaning after itself?
Not really. I simply boot up my machine and wait for the first kmemleak scan.
I am not able to reproduce the issue. Tried with latest net-next on FC26 with kmemleak on. I only got this one after bootup,
'cat /sys/kernel/debug/kmemleak' or
'echo scan > /sys/kernel/debug/kmemleak
Âcat /sys/kernel/debug/kmemleak':
unreferenced object 0xffff99701a7386e0 (size 32):
 comm "mount", pid 1856, jiffies 4294669263 (age 98.440s)
 hex dump (first 32 bytes):
ÂÂÂ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Â ................
ÂÂÂ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Â ................
 backtrace:
ÂÂÂ [<000000004668ec00>] security_sb_parse_opts_str+0x36/0x50
ÂÂÂ [<00000000a9807d2b>] parse_security_options+0x3d/0x60
ÂÂÂ [<00000000cc1e1d58>] btrfs_mount_root+0x139/0x720
ÂÂÂ [<00000000bdc4f1a3>] mount_fs+0x30/0x150
ÂÂÂ [<00000000f189f1bd>] vfs_kern_mount.part.26+0x54/0x100
ÂÂÂ [<0000000093ae5db7>] btrfs_mount+0x184/0x914
ÂÂÂ [<00000000bdc4f1a3>] mount_fs+0x30/0x150
ÂÂÂ [<00000000f189f1bd>] vfs_kern_mount.part.26+0x54/0x100
ÂÂÂ [<000000003b67b9fc>] do_mount+0x5b9/0xc70
ÂÂÂ [<00000000de4073a0>] SyS_mount+0x80/0xd0
ÂÂÂ [<00000000fc5a968a>] do_syscall_64+0x5d/0x110
ÂÂÂ [<000000003d61f5fc>] entry_SYSCALL_64_after_hwframe+0x21/0x86
ÂÂÂ [<00000000458a6ffa>] 0xffffffffffffffff
Not sure whether the above is a true issue or not.
However, by inspecting the code, I do find the trie_free in lpm_trie.c
may have missed freeing the trie memory.
The change likes below should work:
-bash-4.2$ git diff
diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
index 7b469d1..cecb259 100644
--- a/kernel/bpf/lpm_trie.c
+++ b/kernel/bpf/lpm_trie.c
@@ -589,6 +589,7 @@ static void trie_free(struct bpf_map *map)
Âunlock:
ÂÂÂÂÂÂÂ raw_spin_unlock(&trie->lock);
+ÂÂÂÂÂÂ kfree(trie);
also looks like trie_free() is missing
synchronize_rcu() + rcu_barrier()
it doesn't wait for parallel lookup/update/delete to complete
before freeing the elements.
Thanks, Alexei. I will address this in the patch as well.