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

[Catalin Marinas]

On 03/08/06, Jakub Jelinek <jakub@xxxxxxxxxx> wrote:
> On Mon, Jul 24, 2006 at 02:28:03PM +0100, Catalin Marinas wrote:
> > On 24/07/06, Ingo Molnar <mingo@xxxxxxx> wrote:
> > >update: there's also a neat gcc extension trick suggested by Arjan:
> > >__builtin_classify_type(). This converts types into integers!
> >
> > It's not really reliable as it doesn't distinguish well between types.
> > All the structures, no matter what they contain, have the same id
> > (which I think only refers to the fact that it is built-in type,
> > pointer or structure, without differentiation).
>
> __builtin_classify_type () doesn't give types unique ID, it only classifies
> them:
[...]
> All structures are given record_type_class, all unions union_type_class,
> all pointers pointer_type_class, etc.

Yes, I noticed this.

> That doesn't mean you can't use it in the kernel as additional source
> of type checking (in addition to e.g. sizeof and __alignof__).

It is useful indeed, especially for identifying which types could
actually be or contain pointers. However, with the current Linux API,
the only information that can be passed to kmemleak via the alloc
functions is the size information.

My plan is to post a kmemleak update (some bug-fixes) this weekend and
get some wider testing (maybe in the -mm tree). Once people are happy
with the current implementation, I'll try to add more precise type
checking and introduce new functions (macros) like kmalloc_typed and
kmem_cache_create_typed together with Ingo's algorithm for unique type
ids.

There is another improvement that could be made to reduce the false
negatives - allocate slab objects larger than the required size and
change the offset every time the object is re-allocated. I think this
would be useful not only for kmemleak but also for catching possible
object alterations after it was re-allocated.

--
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/