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

[Catalin Marinas]

On 12/06/06, Pekka J Enberg <penberg@xxxxxxxxxxxxxx> wrote:
> On Mon, 12 Jun 2006, Ingo Molnar wrote:
> > > I found at least two unacceptable false positive classes:
> > >
> > >   - 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.

Data and BSS sections are scanned, otherwise it would report a lot of
false positives.

Looking again at this false positive, I might have been wrong in the
first place. Since the iomem_resource is scanned (being in the data
section), there should be a way to get to the "res" pointer, unless
the request_resource() doesn't return NULL (or some other sibling is
freed without calling release_resource).

> On Mon, 12 Jun 2006, Ingo Molnar wrote:
> > >   - drivers/base/platform.c and fs/ext3/dir.c:
> > >     False positive because we allocate memory for struct + some extra
> > >     stuff.
> > >
> > > At least the latter can be fixed as outlined by Catalin in another
> > > mail.
> >
> > yes.
>
> Indeed and should be fixed before inclusion.

... with a slight risk of increasing the false negatives (but reducing
the memleak_padding calls).

The reason for the current implementation - because the type
information is lost in alloc calls, there is no way to know what type
of structure it is and what container_of() macros are used on its
members. The sizeof() value provides an approximation to this but this
assumption is broken once the allocated memory is different from the
size of the allocated structure. The above idea would eliminate these
issues

--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/