All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Sukadev Bhattiprolu <sukadev@us.ibm.com>,
	"Serge E. Hallyn" <serue@us.ibm.com>
Subject: Re: Possible memory leak via alloc_pid()
Date: Sun, 02 Aug 2009 18:44:37 -0700	[thread overview]
Message-ID: <m1ws5lekmy.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090802213528.GA18795@redhat.com> (Oleg Nesterov's message of "Sun\, 2 Aug 2009 23\:35\:28 +0200")

Oleg Nesterov <oleg@redhat.com> writes:

> On 07/31, Catalin Marinas wrote:
>>
>> On Thu, 2009-07-30 at 23:29 +0200, Oleg Nesterov wrote:
>> >
>> > Since you can reproduce the problem easily, perhaps you can use the
>> > hack above to track get/put ?
>> >
>> > 	$ echo pid_of_Xorg > /proc/sys/kernel/xxx
>>
>> Below is the minicom capture. By the time Xorg dies, the count is 2.
>
> Thanks a lot Catalin.
>
>> When logging out, there are two counter incrementing events via
>> sys_wait4 and sys_ioctl, thoush I'm not sure whether they are
>> unbalanced.
>
> wait4() is right, ioctl() looks fine too.
>
>> pgrep Xorg
>> 1519
>> 10:~# pgrep Xorg > /proc/sys/kernel/xxx 
>> XXXXX(1519) ==22
>
> Unfortunately there is nothing which looks like a leak. I gueess it is
> too late to start the tracking.
>
> I'm afraid this won't really help too, but since nobody has a better
> idea for now, perhaps you can do another test?
>
> Pleas rename Xorg to Xorg.origin, and make a simple Xorg script which
> does something like
>
> 	#!/bin/sh
>
> 	echo $$ >> /proc/sys/kernel/xxx
> 	exec /path/to/Xorg.origin $*
>
> perhaps even this is too late, gdm can do a lot before execing.
>
> Please avoid pgrep/ps/etc, proc adds a lot of noise. Better yet, it
> would be nice to start/stop Xorg with /proc unmounted, but I don't
> know is this can work without /proc.

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.

Eric

  reply	other threads:[~2009-08-03  1:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-08 21:33 Possible memory leak via alloc_pid() Catalin Marinas
2009-07-30  0:03 ` Andrew Morton
2009-07-30  0:36   ` Serge E. Hallyn
2009-07-30  9:16     ` Catalin Marinas
2009-07-30 21:29   ` Oleg Nesterov
2009-07-31 10:16     ` Catalin Marinas
2009-08-02 21:35       ` Oleg Nesterov
2009-08-03  1:44         ` Eric W. Biederman [this message]
2009-08-10 16:55           ` Catalin Marinas
2009-08-10 19:21             ` Eric W. Biederman
2009-09-11 11:35         ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1ws5lekmy.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=serue@us.ibm.com \
    --cc=sukadev@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.