From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernd Schubert Subject: Re: [3.1-rc6] kmalloc(64) leak from IDE Date: Fri, 23 Sep 2011 18:34:42 +0200 Message-ID: <4E7CB522.6080208@itwm.fraunhofer.de> References: <20110922072643.GA27232@hostway.ca> <20110922084811.GC17640@liondog.tnic> <20110922202337.GB32661@hostway.ca> <20110923072118.GA13293@liondog.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailgw1.uni-kl.de ([131.246.120.220]:37984 "EHLO mailgw1.uni-kl.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752233Ab1IWQeq (ORCPT ); Fri, 23 Sep 2011 12:34:46 -0400 In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Bjorn Helgaas Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org On 09/23/2011 06:08 PM, Bjorn Helgaas wrote: > On Fri, Sep 23, 2011 at 9:58 AM, Bernd Schubert > wrote: >> On 09/23/2011 09:21 AM, Borislav Petkov wrote: >>> >>> On Thu, Sep 22, 2011 at 01:23:37PM -0700, Simon Kirby wrote: >>>> >>>> Yes, that seems to have made it stop complaining about the IDE path. >>> >>> Good, thanks for testing. It would be great if you left it running for >>> a couple of days like this to see whether there aren't any other issues >>> with the patch. I'll send it with a proper description to Dave soonish >>> since this is a real bug. >>> >>>> All I see from kmemleak now is: >>> >>> Yep, not IDE-related. Adding linux-acpi. >> >> >>> >>>> unreferenced object 0xe7481a00 (size 256): >>>> comm "swapper", pid 1, jiffies 4294892509 (age 515.560s) >>>> hex dump (first 32 bytes): >>>> 00 00 00 28 ff ff ef ff 60 78 4e e7 00 02 00 00 ...(....`xN..... >>>> 47 01 f8 0c f8 0c 01 08 00 00 00 00 0c 03 00 00 G............... >>>> backtrace: >>>> [] kmemleak_alloc+0x27/0x50 >>>> [] __kmalloc+0xf3/0x1c0 >>>> [] pci_acpi_scan_root+0x11e/0x272 >>>> [] acpi_pci_root_add+0x163/0x256 >>>> [] acpi_device_probe+0x3a/0xf4 >>>> [] driver_probe_device+0x68/0x160 >>>> [] __driver_attach+0x89/0x90 >>>> [] bus_for_each_dev+0x48/0x70 >>>> [] driver_attach+0x19/0x20 >>>> [] bus_add_driver+0x17f/0x240 >>>> [] driver_register+0x65/0x120 >>>> [] acpi_bus_register_driver+0x3a/0x3f >>>> [] acpi_pci_root_init+0x1b/0x2a >>>> [] do_one_initcall+0x30/0x160 >>>> [] kernel_init+0x78/0x10c >>>> [] kernel_thread_helper+0x6/0xd >>>> unreferenced object 0xe74e7860 (size 16): >>>> comm "swapper", pid 1, jiffies 4294892509 (age 515.560s) >>>> hex dump (first 16 bytes): >>>> 50 43 49 20 42 75 73 20 30 30 30 30 3a 30 30 00 PCI Bus 0000:00. >>>> backtrace: >>>> [] kmemleak_alloc+0x27/0x50 >>>> [] __kmalloc+0xf3/0x1c0 >>>> [] kvasprintf+0x2e/0x50 >>>> [] kasprintf+0x11/0x20 >>>> [] pci_acpi_scan_root+0x148/0x272 >>>> [] acpi_pci_root_add+0x163/0x256 >>>> [] acpi_device_probe+0x3a/0xf4 >>>> [] driver_probe_device+0x68/0x160 >>>> [] __driver_attach+0x89/0x90 >>>> [] bus_for_each_dev+0x48/0x70 >>>> [] driver_attach+0x19/0x20 >>>> [] bus_add_driver+0x17f/0x240 >>>> [] driver_register+0x65/0x120 >>>> [] acpi_bus_register_driver+0x3a/0x3f >>>> [] acpi_pci_root_init+0x1b/0x2a >>>> [] do_one_initcall+0x30/0x160 >>>> >>>> ...which is probably a separate, non-recurring leak. >>>> >>>>> Also, I'm sure you know IDE is deprecated, so what are the chances of >>>>> moving this box to libata? Also, can you send me your .config pls? >>>> >>>> Yeah, I was going to get around to that eventually. :) Config (and >>>> earlier kmemleak output) here: http://0x.ca/sim/ref/3.1-rc6-blue/ >>> >>> Ok, thanks. >>> >> >> I think I reported those already some time ago: >> >> https://lkml.org/lkml/2011/6/21/95 > > Rats. And you even posted a patch > (https://lkml.org/lkml/2011/6/21/132). I was cc'd, but unfortunately > to an old email address that no longer works. I'll follow up on it > and make sure it's fixed (probably in 3.2 since it's minor and we're > so late in 3.1). Ah great, I thought you are simply too busy to look into it. We are all just changing our mail addresses too often :) Do you mind if I ping you directly once kernel.org is up again? We have a few test systems here, that fail to boot with recent kernels (just a system hard reset). The issue was introduced in between 2.6.27 and 2.6.32 and it is pci mmconfig related, probably due to a troublesome acpi bios. I filled a bugzilla some time ago and never got a responds on it. But I also need to update it with my latest finding... Thanks, Bernd