From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752496AbZH1Vu3 (ORCPT ); Fri, 28 Aug 2009 17:50:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751171AbZH1Vu2 (ORCPT ); Fri, 28 Aug 2009 17:50:28 -0400 Received: from mail-iw0-f204.google.com ([209.85.223.204]:57273 "EHLO mail-iw0-f204.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106AbZH1Vu1 convert rfc822-to-8bit (ORCPT ); Fri, 28 Aug 2009 17:50:27 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=NDQES+gMqSlO8ZKaWPR5F5HR8NGaG/21+37Kvm8EWMhG0XnVWBs5ydaU7FlbWD2GuW jfuzSssYhaa9LAVs1dr6Xni1s5kTjKXGSUmt2HB5Mqxiwf0aqPBvgO+vA4xqtLRVwKPs RGXZxBVNeic6MVBCaGTXtCv/1xwvcb7p1tf1Y= MIME-Version: 1.0 In-Reply-To: <43e72e890908280952j410293fbm47b4b9d566e26c14@mail.gmail.com> References: <43e72e890908272225w79ec5bf6kc7ef1160e5a088ae@mail.gmail.com> <43e72e890908280952j410293fbm47b4b9d566e26c14@mail.gmail.com> From: "Luis R. Rodriguez" Date: Fri, 28 Aug 2009 14:50:09 -0700 Message-ID: <43e72e890908281450k78cc1a2fmd4fd033ae0f4176f@mail.gmail.com> Subject: Re: memleaks, acpi + ext4 + tty To: Catalin Marinas Cc: linux-kernel@vger.kernel.org, "Aneesh Kumar K.V" , Greg Kroah-Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 28, 2009 at 9:52 AM, Luis R. Rodriguez wrote: > On Fri, Aug 28, 2009 at 9:32 AM, Catalin Marinas wrote: >> "Luis R. Rodriguez" 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: >>>     [] create_object+0x13d/0x2d0 >>>     [] kmemleak_alloc+0x25/0x60 >>>     [] kmem_cache_alloc_node+0x193/0x200 >>>     [] process_zones+0x70/0x1cd >>>     [] pageset_cpuup_callback+0x35/0x92 >>>     [] notifier_call_chain+0x47/0x90 >>>     [] __raw_notifier_call_chain+0x9/0x10 >>>     [] _cpu_up+0x75/0x130 >>>     [] cpu_up+0x5a/0x6a >>>     [] kernel_init+0xcc/0x1ba >>>     [] child_rip+0xa/0x20 >>>     [] 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: >>>     [] create_object+0x13d/0x2d0 >>>     [] kmemleak_alloc+0x25/0x60 >>>     [] __kmalloc+0x16b/0x250 >>>     [] kzalloc+0xf/0x11 >>>     [] acpi_add_single_object+0x58e/0xd3c >>>     [] acpi_bus_scan+0x125/0x1af >>>     [] acpi_scan_init+0xc8/0xe9 >>>     [] acpi_init+0x21f/0x265 >>>     [] do_one_initcall+0x4b/0x1b0 >>>     [] kernel_init+0x164/0x1ba >>>     [] child_rip+0xa/0x20 >>>     [] 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: >>>     [] create_object+0x13d/0x2d0 >>>     [] kmemleak_alloc+0x25/0x60 >>>     [] __kmalloc+0x16b/0x250 >>>     [] ext4_mb_init+0x1a1/0x590 >>>     [] ext4_fill_super+0x1df3/0x26c0 >>>     [] get_sb_bdev+0x16f/0x1b0 >>>     [] ext4_get_sb+0x13/0x20 >>>     [] vfs_kern_mount+0x76/0x180 >>>     [] do_kern_mount+0x4d/0x130 >>>     [] do_mount+0x307/0x8b0 >>>     [] sys_mount+0x8f/0xe0 >>>     [] system_call_fastpath+0x16/0x1b >>>     [] 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. OK -- tested rc8 + a pull of your tree into mine. The bootup was really slow and something was just not going right. After a while memleak complained it had 8 kmemleak logs but I was not able to get my system usable enough to cat the file. In cases like these I wish I would hookup my ctrl-alt-del to kexec() a safe kernel. After a long period of time it seems X wished it would start, it tried and then flashed back to the tty. This kept repeating in a loop. I am not sure if the culprit was rc8 or the kmemleak branch merge -- I'll find out after I boot into rc8 in a few. These issues seem to be serious blockers, I don't tend to use video play but I suspect others do, after a decent amount of time playing the system becomes completely unusable. If you have any other patch suggestions let me know. I'll try to read the kmemleak docs too, maybe I can try to figure some of these out. Luis