Re: [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 12/06/06, Ingo Molnar <mingo@elte.hu> wrote:
> * Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:
>
> > > >   - arch/i386/kernel/setup.c:
> > > >     False positive because res pointer is stored in a global instance of
> > > >     struct resource.
> > >
> > > there's no good way around this one but to annotate it in one way or
> > > another.
> >
> > Scanning bss and data sections is too expensive, I guess.  I would
> > prefer we create a separate section for gc roots but what you're
> > suggesting is ok as well.
>
> kmemleak does scan global data sections. I dont know why we dont
> discover this particular pointer though: the resource pointer ought to
> be accessible via the iomem_resource.parent/sibling/child sorted list.
> Hm.

I tested it on my x86 machine and kmemleak is right, this is a leak
because request_resource() returns -EBUSY. Something like the attached
patch fixes it (I'm not sure that's the correct fix, maybe we should
check why the resource overlaps with something else).

--
Catalin

diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
index dd6b0e3..60f5d99 100644
--- a/arch/i386/kernel/setup.c
+++ b/arch/i386/kernel/setup.c
@@ -1332,7 +1332,10 @@ legacy_init_iomem_resources(struct resou
 		res->start = e820.map[i].addr;
 		res->end = res->start + e820.map[i].size - 1;
 		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-		request_resource(&iomem_resource, res);
+		if (request_resource(&iomem_resource, res)) {
+			kfree(res);
+			continue;
+		}
 		if (e820.map[i].type == E820_RAM) {
 			/*
 			 *  We don't know which RAM region contains kernel data,