lkml.org 
[lkml]   [2009]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/14] Kernel memory leak detector
On Mon, 12 Jan 2009 09:51:06 +0000 Catalin Marinas <catalin.marinas@arm.com> wrote:

> Hi Andrew,
>
> On Thu, 2009-01-08 at 14:45 -0800, Andrew Morton wrote:
> > On Fri, 19 Dec 2008 18:12:56 +0000
> > Catalin Marinas <catalin.marinas@arm.com> wrote:
> >
> > > A new kmemleak version is available.
> >
> > Sorry, I'll drop this. The level of code churn in linux-next (during
> > the merge window!) means that I've basically lost confidence that my
> > lameass fixed-up code will still even work.
>
> OK. I noticed some minor conflicts with 2.6.29-rc1 but I'll have a look
> at linux-next as well. IIRC, is the -mm tree based on top of linux-next?

It actually includes linux-next and Linus's tree. -mm is based on the
last-released kernel version (2.6.28, 2.6.29-rc1, etc) and includes
origin.patch (takes it up to current Linus) and linux-next.patch (takes
it up to current linux-next).

> > > git://linux-arm.org/linux-2.6.git kmemleak
> >
> > It might be better to add that to linux-next. If we want to merge
> > kmemleak.
>
> I would feel a bit more comfortable if kmemleak lived for (at least) a
> release cycle in the -mm tree so that it may get wider testing. As I
> said, I mainly tested it on ARM.
>
> If you are OK with this, I'll update the branch and make sure there are
> as few conflicts as possible (the alternative is patches by e-mail and
> based on top of linux-next).

The many trees in linux-next are actually based on current mainline.
So if you can prepare and maintain a tree based on current mainline,
Stephen could integrate that into linux-next, hopefully.



\
 
 \ /
  Last update: 2009-01-12 11:31    [W:0.098 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site