Re: [PATCH 07/10] Remove some of the kmemleak false positives

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

On 11/07/06, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> On 7/11/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > @@ -166,6 +166,9 @@ struct platform_device *platform_device_
> >         struct platform_object *pa;
> >
> >         pa = kzalloc(sizeof(struct platform_object) + strlen(name), GFP_KERNEL);
> > +       /* kmemleak cannot guess the object type because the block
> > +        * size is different from the object size */
> > +       memleak_typeid(pa, struct platform_object);
>
> AFAICT, we about 300 kmalloc and kzalloc calls in the kernel that
> would need this annotation.

Most of them wouldn't need this annotation. The problem here is that
the stored pointer is usually pointing to &pa->pdev.dev and "pa" is
accessed via two container_of macros. There might be a few more cases
like this which I didn't find but I don't expect a large number.

> If we really can't fix the detector to deal with these,

As I posted a few weeks ago, this cannot be done without introducing a
lot of false negatives.

> I would prefer we introduce another memory allocator
> function such as:
>
>     void *kzalloc_extra(size_t obj_size, size_t nr_extra, gfp_t flags);
>
> That would do the right thing for memleak too.

There is another case where extra bytes are added in front of the
structure for alignment (the function could have "before" and "after"
arguments). As I said above there aren't many places where kmemleak
needs this.

As Ingo said in the past, we could better go for precise type
identification/checking in kmalloc and both the kernel and kmemleak
would benefit from this  (but that's a pretty large patch).

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