From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756072Ab3FMPte (ORCPT ); Thu, 13 Jun 2013 11:49:34 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:54914 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751925Ab3FMPtc (ORCPT ); Thu, 13 Jun 2013 11:49:32 -0400 Date: Thu, 13 Jun 2013 16:48:53 +0100 From: Catalin Marinas To: Ben Greear Cc: Linux Kernel Mailing List , netdev Subject: Re: kmemleak reports in kernel 3.9.5+ Message-ID: <20130613154853.GD6530@darko.cambridge.arm.com> References: <51B61982.2050903@candelatech.com> <51B78009.2060808@candelatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B78009.2060808@candelatech.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 11, 2013 at 08:52:41PM +0100, Ben Greear wrote: > On 06/10/2013 03:32 PM, Catalin Marinas wrote: > > On 10 June 2013 19:22, Ben Greear wrote: > >> We had a system go OOM while doing lots of wireless > >> stations. (System had 8GB of RAM, so I suspect a leak). > >> > >> I enabled kmemleak in a 3.9.5 (plus some local patches) and > >> I see the entries below. Any idea if these are real or not? > >> > >> unreferenced object 0xffff880212281c80 (size 128): > >> comm "systemd", pid 1, jiffies 4294682684 (age 1159.517s) > >> hex dump (first 32 bytes): > >> 60 39 27 12 02 88 ff ff 00 02 20 00 00 00 ad de `9'....... ..... > >> 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > >> backtrace: > >> [] kmemleak_alloc+0x73/0x98 > >> [] slab_post_alloc_hook+0x28/0x2a > >> [] __kmalloc+0xf9/0x122 > >> [] kzalloc.clone.0+0xe/0x10 > >> [] fib_default_rule_add+0x25/0x7a > >> [] ip6mr_net_init+0x7e/0x118 [ipv6] > >> [] ops_init+0xd6/0xf7 > >> [] register_pernet_operations+0xc2/0x16b > >> [] register_pernet_subsys+0x2e/0x47 > >> [] 0xffffffffa016db69 > >> [] 0xffffffffa016d109 > >> [] do_one_initcall+0x7f/0x13e > >> [] do_init_module+0x44/0x18f > >> [] load_module+0x14d1/0x168e > >> [] sys_init_module+0xfd/0x101 > >> [] system_call_fastpath+0x16/0x1b > > > > No idea yet. You can try: > > > > echo clear > /sys/kernel/debug/kmemleak > > > > and see if there are more appearing after. All seem to have a common > > allocation path via debug_object_activate -> ... -> > > rcuhead_fixup_activate -> ... -> __debug_object_init. > > I tried the command below, and it printed out quite a few things. Can you send me your .config file? I can't reproduce this. > Also, I read the kmemleak.txt documentation, but a question remains: > > If I enable kmemleak at compile time, but disable it at boot > time using kmemleak=off, is there any significant runtime overhead? You still get the callback into kmemleak for each allocation/freeing but it doesn't walk the stack for the backtrace and it doesn't scan the memory either. I would say the overhead is very small, probably unnoticeable if you already have other debug options enabled. -- Catalin