Re: 3.0-rc3 kmemleak reports

[Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>]

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