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]

Date:	Mon, 24 Nov 2008 10:19:13 +0200
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Catalin Marinas <catalin.marinas@....com>
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

Hi Catalin,

On Fri, 2008-11-21 at 11:07 +0000, Catalin Marinas wrote:
> Hi Pekka,
> 
> 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?

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