linux-kernel - Re: memleaks, acpi + ext4 + tty

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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 28 Aug 2009 09:52:18 -0700
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	linux-kernel@...r.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: memleaks, acpi + ext4 + tty

On Fri, Aug 28, 2009 at 9:32 AM, Catalin Marinas<catalin.marinas@....com> wrote:
> "Luis R. Rodriguez" <mcgrof@...il.com> wrote:
>> I have an assorted collection of kmemleak reports for acpi, ext4 and
>> tty, not sure how to read these yet to fix so figure I'd at least post
>> them. To reproduce I can just dd=/dev/zero to some big file and played
>> some video.
>
> If you do a few echo scan > /sys/kernel/debug/kmemleak, do they
> disappear (i.e. transient false positives)?

Sure, I will once on rc8.

> Which kernel version is this?

v2.6.31-rc7-33172-gf4a9f9a

This is from wireless-testing, which has wireless patches on top of
rc7. John just rebased to rc8 so will give that a shot at work.

>> unreferenced object 0xffff88003e0015c0 (size 64):
>>   comm "swapper", pid 1, jiffies 4294892352
>>   backtrace:
>>     [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>     [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>     [<ffffffff81118a03>] kmem_cache_alloc_node+0x193/0x200
>>     [<ffffffff8152509e>] process_zones+0x70/0x1cd
>>     [<ffffffff81525230>] pageset_cpuup_callback+0x35/0x92
>>     [<ffffffff8152c9b7>] notifier_call_chain+0x47/0x90
>>     [<ffffffff81078549>] __raw_notifier_call_chain+0x9/0x10
>>     [<ffffffff81523f25>] _cpu_up+0x75/0x130
>>     [<ffffffff8152403a>] cpu_up+0x5a/0x6a
>>     [<ffffffff8181969e>] kernel_init+0xcc/0x1ba
>>     [<ffffffff810130ca>] child_rip+0xa/0x20
>>     [<ffffffffffffffff>] 0xffffffffffffffff
>
> Can't really tell. Maybe a false positive caused by kmemleak not
> scanning the pgdata node_zones. Can you post your .config file?

Sure, attached.

>> unreferenced object 0xffff88003cb5f700 (size 64):
>>   comm "swapper", pid 1, jiffies 4294892459
>>   backtrace:
>>     [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>     [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>     [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>     [<ffffffff812bb549>] kzalloc+0xf/0x11
>>     [<ffffffff812bbb53>] acpi_add_single_object+0x58e/0xd3c
>>     [<ffffffff812bc51c>] acpi_bus_scan+0x125/0x1af
>>     [<ffffffff81842361>] acpi_scan_init+0xc8/0xe9
>>     [<ffffffff8184211c>] acpi_init+0x21f/0x265
>>     [<ffffffff8100a05b>] do_one_initcall+0x4b/0x1b0
>>     [<ffffffff81819736>] kernel_init+0x164/0x1ba
>>     [<ffffffff810130ca>] child_rip+0xa/0x20
>>     [<ffffffffffffffff>] 0xffffffffffffffff
>
> I get ACPI reports as well and they may be real leaks. However, I
> didn't have time to analyse the code (pretty complicated reference
> counting).

Heh OK thanks for reviewing them though.

>> unreferenced object 0xffff880039571800 (size 1024):
>>   comm "exe", pid 1168, jiffies 4294893410
>>   backtrace:
>>     [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>     [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>     [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>     [<ffffffff811e1d71>] ext4_mb_init+0x1a1/0x590
>>     [<ffffffff811d2da3>] ext4_fill_super+0x1df3/0x26c0
>>     [<ffffffff8112774f>] get_sb_bdev+0x16f/0x1b0
>>     [<ffffffff811c8fd3>] ext4_get_sb+0x13/0x20
>>     [<ffffffff81127216>] vfs_kern_mount+0x76/0x180
>>     [<ffffffff8112738d>] do_kern_mount+0x4d/0x130
>>     [<ffffffff8113fc57>] do_mount+0x307/0x8b0
>>     [<ffffffff8114028f>] sys_mount+0x8f/0xe0
>>     [<ffffffff81011f02>] system_call_fastpath+0x16/0x1b
>>     [<ffffffffffffffff>] 0xffffffffffffffff
>
> The ext4 reports are real leaks and patch was posted here -
> http://lkml.org/lkml/2009/7/15/62. However, it hasn't been merged into
> mainline yet (I cc'ed Aneesh).
>
> The patch is merged in my "kmemleak-fixes" branch on
> git://linux-arm.org/linux-2.6.git.

Will try to suck them out and try them.

>> unreferenced object 0xffff880006ce0400 (size 1024):
>>   comm "mplayer", pid 5293, jiffies 4295366945
>>   backtrace:
>>     [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>     [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>     [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>     [<ffffffff813021b0>] tty_buffer_request_room+0xc0/0x190
>>     [<ffffffff8130244c>] tty_insert_flip_string+0x3c/0xb0
>>     [<ffffffff81302f49>] pty_write+0x49/0x70
>>     [<ffffffff812fd3b0>] n_tty_write+0x1c0/0x450
>>     [<ffffffff812f9ec1>] tty_write+0x1a1/0x290
>>     [<ffffffff81124518>] vfs_write+0xb8/0x1a0
>>     [<ffffffff81124fcc>] sys_write+0x4c/0x80
>>     [<ffffffff81011f02>] system_call_fastpath+0x16/0x1b
>>     [<ffffffffffffffff>] 0xffffffffffffffff
>
> It could be a real leak as you get several of these. I cc'ed Greg KH
> for any suggestions he may have. It looks like it only happens when
> running mplayer.

It took me a while to figure out how to reproduce, and it really
didn't make sense to see this playing video, why would playing video
affect tty?

  Luis

Download attachment ".config" of type "application/octet-stream" (74472 bytes)