From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753542AbeBKQy0 (ORCPT ); Sun, 11 Feb 2018 11:54:26 -0500 Received: from mail-wr0-f179.google.com ([209.85.128.179]:39834 "EHLO mail-wr0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752496AbeBKQyY (ORCPT ); Sun, 11 Feb 2018 11:54:24 -0500 X-Google-Smtp-Source: AH8x225cWtwpUs87xO4Gk0eYTQiQxIynJK14ss7+3ZIY0hQulAO1g36Uu3wooQBXNHr8jDZGGKw0swhhh61fZi7j9GU= MIME-Version: 1.0 In-Reply-To: References: From: Alexei Starovoitov Date: Sun, 11 Feb 2018 08:54:02 -0800 Message-ID: Subject: Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192): To: Mathieu Malaterre Cc: Alexei Starovoitov , Daniel Borkmann , LKML , Yonghong Song Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?