On 12/06/06, Ingo Molnar <[email protected]> wrote:
* Pekka J Enberg <[email protected]> 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,
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
