linux-kernel - Re: kmemleak reports in kernel 3.9.5+

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 11 Jun 2013 12:52:41 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	Catalin Marinas <catalin.marinas@....com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>
Subject: Re: kmemleak reports in kernel 3.9.5+

On 06/10/2013 03:32 PM, Catalin Marinas wrote:
> On 10 June 2013 19:22, Ben Greear <greearb@...delatech.com> 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:
>>      [<ffffffff815de7bf>] kmemleak_alloc+0x73/0x98
>>      [<ffffffff8118b4d4>] slab_post_alloc_hook+0x28/0x2a
>>      [<ffffffff8118d605>] __kmalloc+0xf9/0x122
>>      [<ffffffff8154946d>] kzalloc.clone.0+0xe/0x10
>>      [<ffffffff81549494>] fib_default_rule_add+0x25/0x7a
>>      [<ffffffffa014f5a9>] ip6mr_net_init+0x7e/0x118 [ipv6]
>>      [<ffffffff8152c992>] ops_init+0xd6/0xf7
>>      [<ffffffff8152cb51>] register_pernet_operations+0xc2/0x16b
>>      [<ffffffff8152cc87>] register_pernet_subsys+0x2e/0x47
>>      [<ffffffffa016db69>] 0xffffffffa016db69
>>      [<ffffffffa016d109>] 0xffffffffa016d109
>>      [<ffffffff8100207f>] do_one_initcall+0x7f/0x13e
>>      [<ffffffff810f3985>] do_init_module+0x44/0x18f
>>      [<ffffffff810f5da7>] load_module+0x14d1/0x168e
>>      [<ffffffff810f6114>] sys_init_module+0xfd/0x101
>>      [<ffffffff815f6599>] 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.


I'll try building a kernel without the extra SLUB debugging
to see if that helps.

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?


[root@...2220-1 ~]# echo clear > /debug/kmemleak;sleep 60;echo scan > /debug/kmemleak; cat /debug/kmemleak
unreferenced object 0xffff88021867e450 (size 40):
   comm "chrony-helper", pid 1138, jiffies 4294699268 (age 91773.781s)
   hex dump (first 32 bytes):
     d0 cf e5 18 02 88 ff ff 80 0b be 19 02 88 ff ff  ................
     01 00 00 00 00 00 00 00 f0 34 a3 12 02 88 ff ff  .........4......
   backtrace:
     [<ffffffff815de7bf>] kmemleak_alloc+0x73/0x98
     [<ffffffff8118b4d4>] slab_post_alloc_hook+0x28/0x2a
     [<ffffffff8118d9a7>] kmem_cache_alloc+0xb2/0x123
     [<ffffffff81316919>] __debug_object_init+0x43/0x35f
     [<ffffffff81316c62>] debug_object_init+0x14/0x16
     [<ffffffff810b4e0a>] rcuhead_fixup_activate+0x2b/0xba
     [<ffffffff81315f12>] debug_object_fixup+0x15/0x1d
     [<ffffffff81316557>] debug_object_activate+0x126/0x139
     [<ffffffff81118e4a>] __call_rcu.clone.1+0x58/0x22a
     [<ffffffff81119065>] call_rcu+0x17/0x19
     [<ffffffff811971f6>] put_object+0x46/0x4a
     [<ffffffff811974e3>] delete_object_full+0x2d/0x32
     [<ffffffff815de663>] kmemleak_free+0x59/0x7a
     [<ffffffff8118bc0a>] slab_free_hook+0x21/0x87
     [<ffffffff8118e888>] kmem_cache_free+0xbe/0x15d
     [<ffffffff811acb71>] __d_free+0x56/0x5b
unreferenced object 0xffff880211893b50 (size 40):
   comm "nmcli", pid 1178, jiffies 4294699660 (age 91773.390s)
   hex dump (first 32 bytes):
     00 00 00 00 00 00 00 00 f0 ac bd 19 02 88 ff ff  ................
     01 00 00 00 00 00 00 00 e0 6c 6e 01 02 88 ff ff  .........ln.....
   backtrace:
     [<ffffffff815de7bf>] kmemleak_alloc+0x73/0x98
     [<ffffffff8118b4d4>] slab_post_alloc_hook+0x28/0x2a
     [<ffffffff8118d9a7>] kmem_cache_alloc+0xb2/0x123
     [<ffffffff81316919>] __debug_object_init+0x43/0x35f
     [<ffffffff81316c62>] debug_object_init+0x14/0x16
     [<ffffffff810b4e0a>] rcuhead_fixup_activate+0x2b/0xba
     [<ffffffff81315f12>] debug_object_fixup+0x15/0x1d
     [<ffffffff81316557>] debug_object_activate+0x126/0x139
     [<ffffffff81118e4a>] __call_rcu.clone.1+0x58/0x22a
     [<ffffffff81119065>] call_rcu+0x17/0x19
     [<ffffffff8119be2b>] file_free+0x31/0x35
     [<ffffffff8119c05a>] __fput+0x1bb/0x1db
     [<ffffffff8119c0ca>] ____fput+0xe/0x10
     [<ffffffff810b48d5>] task_work_run+0x85/0xb0
     [<ffffffff8109ccc1>] do_exit+0x3c9/0x978
     [<ffffffff8109d2f3>] do_group_exit+0x83/0xae
....


Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/