Re: [PATCH 2.6.28-rc5 03/11] kmemleak: Add the memoryallocation/freeing hooks

[Catalin Marinas]

Pekka,

On Mon, 2008-11-24 at 10:19 +0200, Pekka Enberg wrote:
> On Fri, 2008-11-21 at 11:07 +0000, Catalin Marinas wrote:
> > On Thu, 2008-11-20 at 21:30 +0200, Pekka Enberg wrote:
> > > > @@ -2610,6 +2611,9 @@ static struct slab *alloc_slabmgmt(struct kmem_cache *cachep, void *objp,
> > > >                /* Slab management obj is off-slab. */
> > > >                slabp = kmem_cache_alloc_node(cachep->slabp_cache,
> > > >                                              local_flags & ~GFP_THISNODE, nodeid);
> > > > +               /* only scan the list member to avoid false negatives */
> > > > +               memleak_scan_area(slabp, offsetof(struct slab, list),
> > > > +                                 sizeof(struct list_head));
> > > 
> > > I find this comment somewhat confusing. Does it mean we _must_ scan
> > > the list members to avoid false negatives (i.e. leaks that happened
> > > but were not reported) or that if we scan the whole of struct slab, we
> > > get false negatives?
> > 
> > It's been some time since I first added this and I may not remember the
> > full details but it's the latter case - it should avoid scanning
> > slabp->s_mem because (my understanding) is that it may contain a pointer
> > to an allocated block. Kmemleak only allows adding what sections to
> > scan, so in this case only the list_head is relevant.
> > 
> > Let me know if my understanding is correct and I'll make the comment
> > more clear.
> 
> Well, slab->s_mem simply points to the slab (i.e. page) itself. So I
> suppose we need to ignore ->s_mem to avoid scanning the same slab twice?

Kmemleak never scans a block twice (well, during a scanning session), it
just increases a reference count for the objects referred via the
scanned object. Since slab structures are allocated via
kmem_cache_alloc_noe, they'll be tracked by kmemleak and scanned
(otherwise they would be memory leaks).

My understanding is that the ->s_mem value points to the slab itself but
the same pointer might actually be the beginning of an allocated memory
block, hence we get at least one reference to this block.

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