3.0-rc3 kmemleak reports

3.0-rc3 kmemleak reports

[Bernd Schubert]

For some reasons I build a kernel with kmemleak support and got a few 
reports.

(squeeze-x86_64)fslab2:~# cat /sys/kernel/debug/kmemleak

unreferenced object 0xffff8800bf738000 (size 512):
   comm "swapper", pid 1, jiffies 4294892604 (age 48783.440s)
   hex dump (first 32 bytes):
     00 00 00 cc 00 00 00 00 ff ff 3f ce 00 00 00 00  ..........?.....
     c8 e3 49 bf 00 88 ff ff 00 02 00 00 00 00 00 00  ..I.............
   backtrace:
     [<ffffffff813779be>] kmemleak_alloc+0x5e/0xc0
     [<ffffffff8113c3f3>] __kmalloc+0x133/0x1e0
     [<ffffffff812d8ad9>] get_current_resources+0x79/0x1b0
     [<ffffffff8137cdff>] pci_acpi_scan_root+0x14a/0x1a7
     [<ffffffff8137bb30>] acpi_pci_root_add+0x197/0x36b
     [<ffffffff8123179a>] acpi_device_probe+0x50/0x122
     [<ffffffff812a21e7>] really_probe+0x77/0x240
     [<ffffffff812a23eb>] driver_probe_device+0x3b/0x80
     [<ffffffff812a24cb>] __driver_attach+0x9b/0xa0
     [<ffffffff812a14ec>] bus_for_each_dev+0x6c/0xa0
     [<ffffffff812a1f9e>] driver_attach+0x1e/0x20
     [<ffffffff812a1940>] bus_add_driver+0x200/0x2b0
     [<ffffffff812a2b30>] driver_register+0x80/0x150
     [<ffffffff81232705>] acpi_bus_register_driver+0x43/0x45
     [<ffffffff8188df34>] acpi_pci_root_init+0x1e/0x2d
     [<ffffffff81002073>] do_one_initcall+0x43/0x190

unreferenced object 0xffff8801fa6c8948 (size 192):
   comm "swapper", pid 1, jiffies 4294892696 (age 48783.072s)
   hex dump (first 32 bytes):
     00 00 50 df 00 00 00 00 ff ff 6f df 00 00 00 00  ..P.......o.....
     18 1e 7b fa 01 88 ff ff 00 02 00 00 00 00 00 00  ..{.............
   backtrace:
     [<ffffffff813779be>] kmemleak_alloc+0x5e/0xc0
     [<ffffffff8113c3f3>] __kmalloc+0x133/0x1e0
     [<ffffffff812d8ad9>] get_current_resources+0x79/0x1b0
     [<ffffffff8137cdff>] pci_acpi_scan_root+0x14a/0x1a7
     [<ffffffff8137bb30>] acpi_pci_root_add+0x197/0x36b
     [<ffffffff8123179a>] acpi_device_probe+0x50/0x122
     [<ffffffff812a21e7>] really_probe+0x77/0x240
     [<ffffffff812a23eb>] driver_probe_device+0x3b/0x80
     [<ffffffff812a24cb>] __driver_attach+0x9b/0xa0
     [<ffffffff812a14ec>] bus_for_each_dev+0x6c/0xa0
     [<ffffffff812a1f9e>] driver_attach+0x1e/0x20
     [<ffffffff812a1940>] bus_add_driver+0x200/0x2b0
     [<ffffffff812a2b30>] driver_register+0x80/0x150
     [<ffffffff81232705>] acpi_bus_register_driver+0x43/0x45
     [<ffffffff8188df34>] acpi_pci_root_init+0x1e/0x2d
     [<ffffffff81002073>] do_one_initcall+0x43/0x190
unreferenced object 0xffff8801fa7b1e18 (size 16):
   comm "swapper", pid 1, jiffies 4294892696 (age 48783.076s)
   hex dump (first 16 bytes):
     50 43 49 20 42 75 73 20 30 30 30 30 3a 38 30 00  PCI Bus 0000:80.
   backtrace:
     [<ffffffff813779be>] kmemleak_alloc+0x5e/0xc0
     [<ffffffff8113c3f3>] __kmalloc+0x133/0x1e0
     [<ffffffff811f9d17>] kvasprintf+0x57/0x90
     [<ffffffff811f9d88>] kasprintf+0x38/0x40
     [<ffffffff812d8afb>] get_current_resources+0x9b/0x1b0
     [<ffffffff8137cdff>] pci_acpi_scan_root+0x14a/0x1a7
     [<ffffffff8137bb30>] acpi_pci_root_add+0x197/0x36b
     [<ffffffff8123179a>] acpi_device_probe+0x50/0x122
     [<ffffffff812a21e7>] really_probe+0x77/0x240
     [<ffffffff812a23eb>] driver_probe_device+0x3b/0x80
     [<ffffffff812a24cb>] __driver_attach+0x9b/0xa0
     [<ffffffff812a14ec>] bus_for_each_dev+0x6c/0xa0
     [<ffffffff812a1f9e>] driver_attach+0x1e/0x20
     [<ffffffff812a1940>] bus_add_driver+0x200/0x2b0
     [<ffffffff812a2b30>] driver_register+0x80/0x150
     [<ffffffff81232705>] acpi_bus_register_driver+0x43/0x45

Re: 3.0-rc3 kmemleak reports

[Catalin Marinas]

On Tue, Jun 21, 2011 at 11:40:15AM +0200, Bernd Schubert wrote:
> For some reasons I build a kernel with kmemleak support and got a
> few reports.

Do you know if they appear in 2.6.39 as well?

Thanks.

-- 
Catalin

Re: 3.0-rc3 kmemleak reports

[Bernd Schubert]

On 06/21/2011 11:57 AM, Catalin Marinas wrote:
> On Tue, Jun 21, 2011 at 11:40:15AM +0200, Bernd Schubert wrote:
>> For some reasons I build a kernel with kmemleak support and got a
>> few reports.
>
> Do you know if they appear in 2.6.39 as well?

No idea, if it is important I can build a previous kernel version (but 
please, no bisecting, I'm too busy with other things).


Cheers,
Bernd

Re: 3.0-rc3 kmemleak reports

[Catalin Marinas]

On Tue, Jun 21, 2011 at 12:00:25PM +0200, Bernd Schubert wrote:
> On 06/21/2011 11:57 AM, Catalin Marinas wrote:
> >On Tue, Jun 21, 2011 at 11:40:15AM +0200, Bernd Schubert wrote:
> >>For some reasons I build a kernel with kmemleak support and got a
> >>few reports.
> >
> >Do you know if they appear in 2.6.39 as well?
> 
> No idea, if it is important I can build a previous kernel version

It would be good, if you have time, as people can at least restrict the
range of commits to check. It could as well be a kmemleak false
positive, can't tell for sure. The ACPI reports are in general difficult
to identify, unless you find some commit that introduced them.

> (but please, no bisecting, I'm too busy with other things).

No problem, thanks anyway.

Thanks.

-- 
Catalin

Re: 3.0-rc3 kmemleak reports

[Bernd Schubert]

On 06/21/2011 12:18 PM, Catalin Marinas wrote:
> On Tue, Jun 21, 2011 at 12:00:25PM +0200, Bernd Schubert wrote:
>> On 06/21/2011 11:57 AM, Catalin Marinas wrote:
>>> On Tue, Jun 21, 2011 at 11:40:15AM +0200, Bernd Schubert wrote:
>>>> For some reasons I build a kernel with kmemleak support and got a
>>>> few reports.
>>>
>>> Do you know if they appear in 2.6.39 as well?
>>
>> No idea, if it is important I can build a previous kernel version
>
> It would be good, if you have time, as people can at least restrict the
> range of commits to check. It could as well be a kmemleak false
> positive, can't tell for sure. The ACPI reports are in general difficult
> to identify, unless you find some commit that introduced them.

I took a quick glance into get_current_resources() and add_resources() 
and it seems to be rather simple to get memory leaks there. In

get_current_resources():

info.res = kmalloc(size, GFP_KERNEL);

=> gdb shows this is our leaking line.


Now in add_resources():

	if (!pci_use_crs)
		return;

=> First possible leak?

		if (res->flags & IORESOURCE_MEM)
			root = &iomem_resource;
		else if (res->flags & IORESOURCE_IO)
			root = &ioport_resource;
		else
			continue;


=> else branch is a possible leak?


And I think we run into the first leak, as kern.log tells us:

> Jun 20 18:20:00 fslab2 kernel: [    0.375732] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
> Jun 20 18:20:00 fslab2 kernel: [    0.376146] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-03])


Actually that should be simple to fix and I rebooted now with a patch 
applied. I have no idea how to convince thunderbird to not wrap lines, 
so I will send the patch in a separate mail. Will CC you.


Cheers,
Bernd