linux-kernel - Re: [PATCH 2.6.28-rc5 03/11] kmemleak: Add the memory allocation/freeing hooks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1227521925.8377.37.camel@pc1117.cambridge.arm.com>
Date:	Mon, 24 Nov 2008 10:18:45 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	linux-kernel@...r.kernel.org, Matt Mackall <mpm@...enic.com>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [PATCH 2.6.28-rc5 03/11] kmemleak: Add the memory
	allocation/freeing hooks

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/