Messages in this thread | | | Subject | Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192): | From | Yonghong Song <> | Date | Mon, 12 Feb 2018 09:00:24 -0800 |
| |
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@gmail.com> wrote: >>>>> On Sun, Feb 11, 2018 at 7:24 AM, Mathieu Malaterre <malat@debian.org> 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.
| |