To: Catalin Marinas <catalin.marinas@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.17-rc4 1/6] Base support for kmemleak
References: <20060513155757.8848.11980.stgit@localhost.localdomain>
	<20060513160541.8848.2113.stgit@localhost.localdomain>
From: Andi Kleen <ak@suse.de>
Date: 14 May 2006 01:20:40 +0200
In-Reply-To: <20060513160541.8848.2113.stgit@localhost.localdomain>
Message-ID: <p73u07t5x6f.fsf@bragg.suse.de>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1048
Lines: 20

Catalin Marinas <catalin.marinas@gmail.com> writes:

> From: Catalin Marinas <catalin.marinas@arm.com>
> 
> This patch adds the base support for the kernel memory leak detector. It
> traces the memory allocation/freeing in a way similar to the Boehm's
> conservative garbage collector, the difference being that the orphan
> pointers are not freed but only shown in /proc/memleak. Enabling this
> feature would introduce an overhead to memory allocations.

Interesting approach. Did you actually find any leaks with this? 

What looks a bit dubious is how objects reuse is handled. You can't
distingush an reused object from an old leaked pointer. But due
to the way slab allocates this should be pretty common. I guess
for your approach to be effective slab would need to be changed
to a queue?

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/