lkml.org 
[lkml]   [2009]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: memleaks, acpi + ext4 + tty
On Fri, Aug 28, 2009 at 9:32 AM, Catalin Marinas<catalin.marinas@arm.com> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.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
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2009-08-28 18:55    [W:0.172 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site