From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932957AbeBLI2m (ORCPT ); Mon, 12 Feb 2018 03:28:42 -0500 Received: from www62.your-server.de ([213.133.104.62]:47322 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932785AbeBLI2l (ORCPT ); Mon, 12 Feb 2018 03:28:41 -0500 Subject: Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192): To: Yonghong Song , Mathieu Malaterre , Alexei Starovoitov Cc: Alexei Starovoitov , LKML References:

<3fa5958d-c14e-56bd-de49-84fc43db4b32@fb.com> From: Daniel Borkmann Message-ID: <609d04c4-f947-ede5-3c4f-28eaf0b14745@iogearbox.net> Date: Mon, 12 Feb 2018 09:28:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3fa5958d-c14e-56bd-de49-84fc43db4b32@fb.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> wrote: >>> On Sun, Feb 11, 2018 at 7:24 AM, Mathieu Malaterre 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 >>>> [] 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 >>>> [] 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); > } > > static int trie_get_next_key(struct bpf_map *map, void *_key, void *_next_key) > -bash-4.2$ > > Will propose a formal patch for this soon. Agree, good catch, and I also think that this is the issue, since this is what kmemleak reports in terms of size (192): struct lpm_trie { struct bpf_map map; /* 0 128 */ /* --- cacheline 2 boundary (128 bytes) --- */ struct lpm_trie_node * root; /* 128 8 */ size_t n_entries; /* 136 8 */ size_t max_prefixlen; /* 144 8 */ size_t data_size; /* 152 8 */ raw_spinlock_t lock; /* 160 4 */ /* size: 192, cachelines: 3, members: 6 */ /* padding: 28 */ };