3.0-rc3 kmemleak reports

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

Do you know if they appear in 2.6.39 as well?

Thanks.

Catalin

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

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.

No problem, thanks anyway.

Thanks.

Catalin

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:

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