lkml.org 
[lkml]   [2018]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [kmemleak] unreferenced object 0xcd9c1a80 (size 192):
From
Date


On 2/11/18 11:18 AM, Mathieu Malaterre wrote:
> Hi,
>
> 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);
}

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.


>

\
 
 \ /
  Last update: 2018-02-12 06:48    [W:0.059 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site