kmemleak reports

kmemleak reports

[Kevin Winchester]

Hi Catalin,

I have noticed a few kmemleak reports being sent to LKML in the last few days, and I could chime in with mine, if you wish:

    kmemleak: 97 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

The entries are for X, ntpdate, scsi_scan_2, softirq, swapper, in case there's anything surprising in there.

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?

If a kerneloops-style setup is not desirable/feasible, would you be able to send me a walkthrough for how you go about tracking down one of these leaks?  Then I might be able to help out by investigating a few of my own.

Thanks,

-- 
Kevin Winchester

Re: kmemleak reports

[Catalin Marinas]

On Tue, 2009-07-14 at 20:28 -0300, Kevin Winchester wrote:
> I have noticed a few kmemleak reports being sent to LKML in the last
> few days, and I could chime in with mine, if you wish:
> 
>     kmemleak: 97 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

That's not unlikely, though several of reports may come from a single
place (a user-space script could be used to group them together).

> The entries are for X, ntpdate, scsi_scan_2, softirq, swapper, in case
> there's anything surprising in there.

As I mentioned in the past, you can run a few "echo scan
> /sys/kernel/debug/kmemleak" to see if any of them disappear.

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

The leaks are reported in the order they were allocated and this makes
it easier to debug (since an early leak may trigger subsequent reports
on pointers it contains since it isn't scanned).

My hope is that once the initial leaks are fixed, there will be less in
the future and could be easily linked to recent commits (which is not
always the case now).

I don't have the time to set up something like kerneloops but I'm happy
to manually log them somewhere (like bugzilla.kernel.org).
Alternatively, kerneloops.org could detect kmemleak reports on the list
and log them.

> If a kerneloops-style setup is not desirable/feasible, would you be
> able to send me a walkthrough for how you go about tracking down one
> of these leaks?  Then I might be able to help out by investigating a
> few of my own.

First, make sure you use -rc3 as it has several kmemleak fixes. On
x86_64, there is another patch I posted for moving the _edata in
vmlinux.lds.S to be able to scan the whole .data section.

I gave some hints in this message - http://lkml.org/lkml/2009/7/14/72.
I'll also update the Documentation/kmemleak.txt file with such
information in the next few days.

-- 
Catalin

Re: kmemleak reports

[Catalin Marinas]

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.

I'll try to set this up, ideally on kernel.org for wider visibility (if
I manage to get an account, otherwise on linux-arm.org/git where I
usually keep my trees).

-- 
Catalin

Re: kmemleak reports

[Catalin Marinas]

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