Subject: Re: kmemleak reports
From: Catalin Marinas <catalin.marinas@arm.com>
To: Kevin Winchester <kjwinchester@gmail.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
       LKML <linux-kernel@vger.kernel.org>
In-Reply-To: <1247735505.24965.15.camel@pc1117.cambridge.arm.com>
References: <4A5D148A.5090405@gmail.com>
	 <1247735505.24965.15.camel@pc1117.cambridge.arm.com>
Content-Type: text/plain
Organization: ARM Ltd
Date: Thu, 16 Jul 2009 17:13:18 +0100
Message-Id: <1247760798.27689.19.camel@pc1117.cambridge.arm.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1401
Lines: 30

On Thu, 2009-07-16 at 10:11 +0100, Catalin Marinas wrote:
> On Tue, 2009-07-14 at 20:28 -0300, Kevin Winchester wrote:
> > However, I was thinking that you might soon start getting too many
> > reports to process.  I wonder if there might be some way that you
> > could have a similar facility to kerneloops that would automatically
> > register leak reports to a website where they could be organized and
> > ranked by number of occurrences.  Are the individual leaks reported in
> > such at way that would allow them to be grouped like that?
> 
> BTW, a step towards reducing the number of reports on the list is to
> maintain a tree based on the mainline which gathers various fixes posted
> by people. It is up to the maintainers to push them upstream but, in the
> meantime, people could try this tree and avoid reporting the same
> issues.

The first step - I created a branch for tracking the leak fixes posted
so far. This branch can be repeatedly merged (it is not rebased, or,
more exactly, it is rebased but benefits from the recent stgit publish
command to make rebasing invisible):

	git://linux-arm.org/linux-2.6 kmemleak-fixes

-- 
Catalin

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