From: ebiederm@xmission.com (Eric W. Biederman)
To: Mike Galbraith <efault@gmx.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Pavel Emelyanov <xemul@parallels.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Louis Rilling <louis.rilling@kerlabs.com>
Subject: Re: [PATCH] Re: [RFC PATCH] namespaces: fix leak on fork() failure
Date: Fri, 04 May 2012 01:03:36 -0700 [thread overview]
Message-ID: <m1sjfggyp3.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1336057018.8119.46.camel@marge.simpson.net> (Mike Galbraith's message of "Thu, 03 May 2012 16:56:58 +0200")
Mike Galbraith <efault@gmx.de> writes:
> On Thu, 2012-05-03 at 05:12 +0200, Mike Galbraith wrote:
>> On Tue, 2012-05-01 at 13:42 -0700, Andrew Morton wrote:
>> > On Tue, 01 May 2012 13:35:03 -0700
>> > ebiederm@xmission.com (Eric W. Biederman) wrote:
>> >
>> > >
>> > > Andrew can you please pick up this patch?
>> >
>> > Sure. I assume it's fixing a post-3.4 regression? No -stable backport
>> > needed?
>>
>> Dunno what all should go to stable, but anyone using vsftpd will
>> appreciate something going. Large leakage was initially reported
>> against 3.1. That was bisected to..
>> 423e0ab0 VFS : mount lock scalability for internal mounts
>>
>> Subsequent fixes which did not go to stable were applied..
>> 905ad269 procfs: fix a vfsmount longterm reference leak
>> 6f686574 ... and the same kind of leak for mqueue
>> ..but leakage persists even with fork failure hole plugged.
>
>> Whatever goes to stable, what fixes this little bugger should go too.
>
> Finally have a decent trace, patch to fix the problem below.
>
> marge:~ # grep 0xffff8801fad5dff0 /trace3
> vsftpd-18277 [003] .... 1779.012239: proc_set_super: get_pid_ns: 0xffff8801fad5dff0 count:1->2
> vsftpd-18277 [003] .... 1779.012253: create_pid_namespace: create_pid_namespace: 0xffff8801fad5dff0
> vsftpd-18277 [003] .... 1779.012258: alloc_pid: get_pid_ns: 0xffff8801fad5dff0 count:2->3
> vsftpd-18277 [003] .... 1779.012278: proc_kill_sb: put_pid_ns: 0xffff8801fad5dff0 count:3->2
> ksoftirqd/3-16 [003] ..s. 1779.012731: delayed_put_pid: put_pid_ns: 0xffff8801fad5dff0 count:2->1
> vsftpd-18277 [003] .... 1779.015614: destroy_pid_namespace: destroy_pid_namespace: 0xffff8801fad5dff0
> vsftpd-18277 [003] .... 1779.015614: free_nsproxy: put_pid_ns: 0xffff8801fad5dff0 count:1->0
> vsftpd-18277 [003] .... 1779.249871: proc_set_super: get_pid_ns: 0xffff8801fad5dff0 count:1->2
> vsftpd-18277 [003] .... 1779.249884: create_pid_namespace: create_pid_namespace: 0xffff8801fad5dff0
> vsftpd-18277 [003] .... 1779.249888: alloc_pid: get_pid_ns: 0xffff8801fad5dff0 count:2->3
> vsftpd-18351 [003] .... 1779.256337: switch_task_namespaces: exiting: 0xffff8801fad5dff0 count:3
> vsftpd-18351 [003] .... 1779.266243: free_nsproxy: put_pid_ns: 0xffff8801fad5dff0 count:3->2
> <insert>
> ps-18381 [000] .... 1779.298798: proc_fill_cache <-proc_pid_readdir
> ps-18381 [000] .... 1779.298802: proc_pid_instantiate <-proc_fill_cache
> ps-18381 [000] .... 1779.298802: proc_pid_make_inode <-proc_pid_instantiate
> ps-18381 [000] .... 1779.298802: proc_alloc_inode <-alloc_inode
> ps-18381 [000] .... 1779.298807: get_task_pid <-proc_pid_make_inode
> ps-18381 [000] .... 1779.298807: get_pid <-get_task_pid
> </insert> ditto for other pid references added post task exit
> ps-18381 [000] .... 1779.298807: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:1->2 pid_ns count:2
> ps-18381 [001] .... 1779.327593: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:2->3 pid_ns count:2
> ps-18381 [001] .... 1779.327653: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:3->4 pid_ns count:2
> ps-18381 [001] .... 1779.327716: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:4->5 pid_ns count:2
> ps-18381 [001] .... 1779.327804: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:5->6 pid_ns count:2
> ps-18381 [001] .... 1779.327817: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:6->7 pid_ns count:2
> ps-18381 [001] .... 1779.327818: put_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:7->6 pid_ns count:2
> vsftpd-18277 [003] .... 1779.358887: put_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:6->5 pid_ns count:2
> vsftpd-18277 [003] .... 1779.358889: put_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:5->4 pid_ns count:2
> vsftpd-18277 [003] .... 1779.358891: put_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:4->3 pid_ns count:2
> vsftpd-18277 [003] .... 1779.358894: put_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:3->2 pid_ns count:2
> vsftpd-18277 [003] .... 1779.358897: put_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:2->1 pid_ns count:2
> vsftpd-18277 [003] .... 1779.358918: proc_kill_sb: put_pid_ns: 0xffff8801fad5dff0 count:2->1
> ps-18386 [001] .... 1779.370210: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:1->2 pid_ns count:1
> ps-18386 [001] .... 1779.370240: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:2->3 pid_ns count:1
> ps-18386 [001] .... 1779.370300: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:3->4 pid_ns count:1
> ps-18386 [001] .... 1779.370361: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:4->5 pid_ns count:1
> ps-18386 [001] .... 1779.370454: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:5->6 pid_ns count:1
> ps-18386 [001] .... 1779.370467: get_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:6->7 pid_ns count:1
> ps-18386 [001] .... 1779.370468: put_pid: pid: 0xffff8802031a2fc0 namespace: 0xffff8801fad5dff0 pid count:7->6 pid_ns count:1
> ksoftirqd/3-16 [003] ..s. 1779.390717: delayed_put_pid: pid: 0xffff8802031a2fc0 LEAKED namespace: 0xffff8801fad5dff0
>
> Ok, that seems reasonable.
>
> Create > 27k "leaked" namespaces, watch many thousands go away over
> time.. but many hundred persist and persist and persist.
>
> Hm. echo 3 > /proc/sys/vm/drop_caches.. *poof gone*
Good to hear. I am sad to hear that proc_flush_task isn't doing a
better job but at least memory pressure will now free everything up as
it is supposed to.
> Grr. I wonder who is doing the pinning when I don't monitor, but..
>
> <patch>
> kick kick kick... it's dead Jim.
> </patch>
Are you saying all known bugs are fixed? Thanks for digging into this
by the way. A fresh set of eyeballs is always nice.
Eric
next prev parent reply other threads:[~2012-05-04 7:59 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-28 9:19 [RFC PATCH] namespaces: fix leak on fork() failure Mike Galbraith
2012-04-28 14:26 ` Oleg Nesterov
2012-04-29 4:13 ` Mike Galbraith
2012-04-29 7:57 ` Eric W. Biederman
2012-04-29 9:49 ` Mike Galbraith
2012-04-29 16:58 ` Oleg Nesterov
2012-04-30 2:59 ` Eric W. Biederman
2012-04-30 3:25 ` Mike Galbraith
2012-05-02 12:40 ` Oleg Nesterov
2012-05-02 17:37 ` Eric W. Biederman
2012-04-30 3:01 ` [PATCH] " Mike Galbraith
[not found] ` <m1zk9rmyh4.fsf@fess.ebiederm.org>
2012-05-01 20:42 ` Andrew Morton
2012-05-03 3:12 ` Mike Galbraith
2012-05-03 14:56 ` Mike Galbraith
2012-05-04 4:27 ` Mike Galbraith
2012-05-04 7:55 ` Eric W. Biederman
2012-05-04 8:34 ` Mike Galbraith
2012-05-04 9:45 ` Mike Galbraith
2012-05-04 14:13 ` Eric W. Biederman
2012-05-04 14:49 ` Mike Galbraith
2012-05-04 15:36 ` Eric W. Biederman
2012-05-04 16:57 ` Mike Galbraith
2012-05-04 20:29 ` Eric W. Biederman
2012-05-05 5:56 ` Mike Galbraith
2012-05-05 6:08 ` Mike Galbraith
2012-05-05 7:12 ` Mike Galbraith
2012-05-05 11:37 ` Eric W. Biederman
2012-05-07 21:51 ` [PATCH] vfs: Speed up deactivate_super for non-modular filesystems Eric W. Biederman
2012-05-07 22:17 ` Al Viro
2012-05-07 23:56 ` Paul E. McKenney
2012-05-08 1:07 ` Eric W. Biederman
2012-05-08 4:53 ` Mike Galbraith
2012-05-09 7:55 ` Nick Piggin
2012-05-09 11:02 ` Eric W. Biederman
2012-05-09 11:02 ` Eric W. Biederman
2012-05-15 8:40 ` Nick Piggin
2012-05-16 0:34 ` Eric W. Biederman
2012-05-16 0:34 ` Eric W. Biederman
2012-05-09 13:59 ` Paul E. McKenney
2012-05-04 8:03 ` Eric W. Biederman [this message]
2012-05-04 8:19 ` [PATCH] Re: [RFC PATCH] namespaces: fix leak on fork() failure Mike Galbraith
2012-05-04 8:54 ` Mike Galbraith
2012-05-07 0:32 ` [PATCH 0/3] pidns: Closing the pid namespace exit race Eric W. Biederman
2012-05-07 0:33 ` [PATCH 1/3] pidns: Use task_active_pid_ns in do_notify_parent Eric W. Biederman
2012-05-07 0:35 ` [PATCH 2/3] pidns: Guarantee that the pidns init will be the last pidns process reaped Eric W. Biederman
2012-05-08 22:50 ` Andrew Morton
2012-05-16 18:39 ` Oleg Nesterov
2012-05-16 19:34 ` Oleg Nesterov
2012-05-16 20:54 ` Eric W. Biederman
2012-05-17 17:00 ` Oleg Nesterov
2012-05-17 21:46 ` Eric W. Biederman
2012-05-18 12:39 ` Oleg Nesterov
2012-05-19 0:03 ` Eric W. Biederman
2012-05-21 12:44 ` Oleg Nesterov
2012-05-22 0:16 ` Eric W. Biederman
2012-05-22 0:20 ` [PATCH] pidns: Guarantee that the pidns init will be the last pidns process reaped. v2 Eric W. Biederman
2012-05-22 16:54 ` Oleg Nesterov
2012-05-22 19:23 ` Andrew Morton
2012-05-23 14:52 ` Oleg Nesterov
2012-05-25 15:15 ` [PATCH -mm] pidns-guarantee-that-the-pidns-init-will-be-the-last-pidns-process-r eaped-v2-fix-fix Oleg Nesterov
2012-05-25 15:59 ` [PATCH -mm 0/1] pidns: find_new_reaper() can no longer switch to init_pid_ns.child_reaper Oleg Nesterov
2012-05-25 16:00 ` [PATCH -mm 1/1] " Oleg Nesterov
2012-05-25 21:43 ` Eric W. Biederman
2012-05-27 19:10 ` [PATCH v2 -mm 0/1] " Oleg Nesterov
2012-05-27 19:11 ` [PATCH v2 -mm 1/1] " Oleg Nesterov
2012-05-29 6:34 ` Eric W. Biederman
2012-05-25 21:25 ` [PATCH -mm] pidns-guarantee-that-the-pidns-init-will-be-the-last-pidns-process-r eaped-v2-fix-fix Eric W. Biederman
2012-05-27 18:41 ` [PATCH -mm v2] " Oleg Nesterov
2012-05-07 0:35 ` [PATCH 3/3] pidns: Make killed children autoreap Eric W. Biederman
2012-05-08 22:51 ` Andrew Morton
2012-04-30 13:57 ` [RFC PATCH] namespaces: fix leak on fork() failure Mike Galbraith
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=m1sjfggyp3.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=efault@gmx.de \
--cc=gorcunov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=louis.rilling@kerlabs.com \
--cc=oleg@redhat.com \
--cc=xemul@parallels.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.