linux-kernel - Re: [PATCH 03/15] kmemleak: Add the slab 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] [day] [month] [year] [list]

Message-Id: <1229683489.23599.3.camel@pc1117.cambridge.arm.com>
Date:	Fri, 19 Dec 2008 10:44:49 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/15] kmemleak: Add the slab memory allocation/freeing
	hooks

On Thu, 2008-12-18 at 15:41 -0600, Christoph Lameter wrote:
> On Thu, 18 Dec 2008, Pekka Enberg wrote:
> 
> > For kmemleak, that's a problem. Unless we explicitly annotate the
> > caches, it will scan them and think that there's a pointer to a leaked
> > object (i.e. false negative). Catalin already took care of the per-CPU
> > caches but AFAICT we still need to take care of the per-node caches
> > and the shared caches.
> 
> Why doesnt kmemleak simply use the counter as a boundary and only access
> those pointers that are valid?

Since the valid pointers in these caches only point to freed objects
(which aren't tracked by kmemleak), it's better for kmemleak not to scan
such structures at all. I added a kmemleak_no_scan() annotation for
this.

Thanks for clarification.

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