[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1249923358.10848.75.camel@pc1117.cambridge.arm.com>
Date: Mon, 10 Aug 2009 17:55:58 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Sukadev Bhattiprolu <sukadev@...ibm.com>,
"Serge E. Hallyn" <serue@...ibm.com>
Subject: Re: Possible memory leak via alloc_pid()
On Sun, 2009-08-02 at 18:44 -0700, Eric W. Biederman wrote:
> Hmm. I'm starting to wonder if kmemleak is right. I don't know how
> it works but something about the way pids are used might be confusing it.
It could as well be a false positive but I can't find its source.
Basically, the pid structure for the dead Xorg is still allocated
minutes after Xorg died with a pid->count of 2. Kmemleak scans the data
and bss sections, task stacks and most of the allocated objects (which
are not reported as leaks) but cannot find a pointer to this pid
structure (or anywhere inside it like pid->number.pid_chain).
The supposedly leaked pid structure also have pid_chain.pprev ==
LIST_POISON2 which means that it was already removed from the pid_hash
(this block of memory is scanned by kmemleak anyway).
The free_pid() function was also called on this object according to the
pid->rcu values but put_pid() couldn't free it because of pid->count.
If this structure in not on pid_hash, is there any other place where its
pointer may be stored for a long time? Otherwise it looks like a real
leak (though not a big one).
I'll do more tests in the next few days as suggested by Oleg.
--
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/
Powered by blists - more mailing lists