From: Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Cc: jack-+ZI9xUNit7I@public.gmane.org,
Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
mingo-X9Un+BFzKDI@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
andrea-Vyt77T80VFVWk0Htik3J/w@public.gmane.org,
dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org,
Sukadev Bhattiprolu
<sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
Alexey Dobriyan
<adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] pidns: Fix a leak in /proc inodes and dentries
Date: Tue, 20 Oct 2009 13:58:34 +0200 [thread overview]
Message-ID: <4ADDA5EA.2060200@fr.ibm.com> (raw)
In-Reply-To: <m1r5sywebv.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
On 10/20/2009 12:27 PM, Eric W. Biederman wrote:
> Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
>
>> Fix a leak in /proc dentries and inodes with pid namespaces.
>>
>> This fix reverts the commit 7766755a2f249e7e0. The leak was reported by
>> Daniel Lezcano - see http://lkml.org/lkml/2009/10/2/159.
>>
>> To summarize the thread, when container-init is terminated, it sets the
>> PF_EXITING flag and then zaps all the other processes in the container.
>> When those processes exit, they are expected to be reaped by the container-
>> init and as a part of reaping, the container-init should flush any /proc
>> dentries associated with the processes. But because the container-init is
>> itself exiting and the following PF_EXITING check, the dentires are not
>> flushed, resulting in leak in /proc inodes and dentries.
>
> Acked-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
there's indeed a lot of progress. A run of our C/R testsuite (spawning and
killing a few thousands pidns) used to leak ~700MB of slab, it's now gone.
thanks suka for spending time on this.
but we still have some minor leaks. below are contents of /proc/slabinfo
before and after the run, you will notice that in some cases, dangling refs
of nsproxy and pid_namespace are still alive. I wonder if there are some
cases when this can happen, else I'll try to reproduce it.
Cheers,
C.
* slabinfo.qemu (i686)
pid_namespace 0 0 64 59 1
nsproxy 0 0 48 78 1
proc_inode_cache 193 193 4096 1 1
dentry 6734 6734 4096 1 1
pid_2 0 0 88 44 1
pid_namespace 0 0 64 59 1
nsproxy 0 0 48 78 1
proc_inode_cache 4 4 4096 1 1
dentry 36112 36112 4096 1 1
* slabinfo.a13.test.meiosys.com (ppc64)
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 506 513 4096 1 1
dentry 6269 6272 280 14 1
pid_2 1 28 136 28 1
pid_namespace 1 1 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 486 498 4096 1 1
dentry 49051 49448 280 14 1
* slabinfo.f13.test.meiosys.com (ppc64)
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 248 263 4096 1 1
dentry 7359 7364 280 14 1
pid_2 0 0 136 28 1
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 240 240 4096 1 1
dentry 50253 50666 280 14 1
* slabinfo.r3-23.test.meiosys.com (x86_64)
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 479 495 4096 1 1
dentry 5614 5614 280 14 1
pid_2 1 28 136 28 1
pid_namespace 1 1 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 576 576 4096 1 1
dentry 52202 52444 280 14 1
* slabinfo.r3-24.test.meiosys.com (x86_64)
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 464 486 4096 1 1
dentry 5698 5698 280 14 1
pid_2 0 0 136 28 1
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 448 448 4096 1 1
dentry 51845 52164 280 14 1
* slabinfo.r3-26.test.meiosys.com (i686)
pid_namespace 0 0 64 59 1
nsproxy 0 0 48 78 1
proc_inode_cache 449 466 4096 1 1
dentry 5633 5633 4096 1 1
pid_2 0 0 88 44 1
pid_namespace 0 0 64 59 1
nsproxy 0 0 48 78 1
proc_inode_cache 448 448 4096 1 1
dentry 52039 52039 4096 1 1
* slabinfo.linuz12 (s390x)
pid_namespace 0 0 2112 3 2
nsproxy 0 0 48 77 1
proc_inode_cache 725 798 640 6 1
dentry 4340 4340 192 20 1
pid_2 1 30 128 30 1
pid_namespace 1 3 2112 3 2
nsproxy 1 77 48 77 1
proc_inode_cache 74 180 640 6 1
dentry 34511 36820 192 20 1
WARNING: multiple messages have this Message-ID (diff)
From: Cedric Le Goater <clg@fr.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
jack@ucw.cz, Containers <containers@lists.linux-foundation.org>,
linux-kernel@vger.kernel.org, andrea@cpushare.com,
Alexey Dobriyan <adobriyan@gmail.com>,
dlezcano@fr.ibm.com, mingo@elte.hu,
Pavel Emelyanov <xemul@openvz.org>
Subject: Re: [PATCH] pidns: Fix a leak in /proc inodes and dentries
Date: Tue, 20 Oct 2009 13:58:34 +0200 [thread overview]
Message-ID: <4ADDA5EA.2060200@fr.ibm.com> (raw)
In-Reply-To: <m1r5sywebv.fsf@fess.ebiederm.org>
On 10/20/2009 12:27 PM, Eric W. Biederman wrote:
> Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:
>
>> Fix a leak in /proc dentries and inodes with pid namespaces.
>>
>> This fix reverts the commit 7766755a2f249e7e0. The leak was reported by
>> Daniel Lezcano - see http://lkml.org/lkml/2009/10/2/159.
>>
>> To summarize the thread, when container-init is terminated, it sets the
>> PF_EXITING flag and then zaps all the other processes in the container.
>> When those processes exit, they are expected to be reaped by the container-
>> init and as a part of reaping, the container-init should flush any /proc
>> dentries associated with the processes. But because the container-init is
>> itself exiting and the following PF_EXITING check, the dentires are not
>> flushed, resulting in leak in /proc inodes and dentries.
>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
there's indeed a lot of progress. A run of our C/R testsuite (spawning and
killing a few thousands pidns) used to leak ~700MB of slab, it's now gone.
thanks suka for spending time on this.
but we still have some minor leaks. below are contents of /proc/slabinfo
before and after the run, you will notice that in some cases, dangling refs
of nsproxy and pid_namespace are still alive. I wonder if there are some
cases when this can happen, else I'll try to reproduce it.
Cheers,
C.
* slabinfo.qemu (i686)
pid_namespace 0 0 64 59 1
nsproxy 0 0 48 78 1
proc_inode_cache 193 193 4096 1 1
dentry 6734 6734 4096 1 1
pid_2 0 0 88 44 1
pid_namespace 0 0 64 59 1
nsproxy 0 0 48 78 1
proc_inode_cache 4 4 4096 1 1
dentry 36112 36112 4096 1 1
* slabinfo.a13.test.meiosys.com (ppc64)
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 506 513 4096 1 1
dentry 6269 6272 280 14 1
pid_2 1 28 136 28 1
pid_namespace 1 1 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 486 498 4096 1 1
dentry 49051 49448 280 14 1
* slabinfo.f13.test.meiosys.com (ppc64)
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 248 263 4096 1 1
dentry 7359 7364 280 14 1
pid_2 0 0 136 28 1
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 240 240 4096 1 1
dentry 50253 50666 280 14 1
* slabinfo.r3-23.test.meiosys.com (x86_64)
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 479 495 4096 1 1
dentry 5614 5614 280 14 1
pid_2 1 28 136 28 1
pid_namespace 1 1 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 576 576 4096 1 1
dentry 52202 52444 280 14 1
* slabinfo.r3-24.test.meiosys.com (x86_64)
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 464 486 4096 1 1
dentry 5698 5698 280 14 1
pid_2 0 0 136 28 1
pid_namespace 0 0 4096 1 1
nsproxy 0 0 72 53 1
proc_inode_cache 448 448 4096 1 1
dentry 51845 52164 280 14 1
* slabinfo.r3-26.test.meiosys.com (i686)
pid_namespace 0 0 64 59 1
nsproxy 0 0 48 78 1
proc_inode_cache 449 466 4096 1 1
dentry 5633 5633 4096 1 1
pid_2 0 0 88 44 1
pid_namespace 0 0 64 59 1
nsproxy 0 0 48 78 1
proc_inode_cache 448 448 4096 1 1
dentry 52039 52039 4096 1 1
* slabinfo.linuz12 (s390x)
pid_namespace 0 0 2112 3 2
nsproxy 0 0 48 77 1
proc_inode_cache 725 798 640 6 1
dentry 4340 4340 192 20 1
pid_2 1 30 128 30 1
pid_namespace 1 3 2112 3 2
nsproxy 1 77 48 77 1
proc_inode_cache 74 180 640 6 1
dentry 34511 36820 192 20 1
next prev parent reply other threads:[~2009-10-20 11:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 4:13 [PATCH] pidns: Fix a leak in /proc inodes and dentries Sukadev Bhattiprolu
[not found] ` <20091020041337.GA31623-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-10-20 10:27 ` Eric W. Biederman
2009-10-20 12:09 ` Alexey Dobriyan
2009-10-20 10:27 ` Eric W. Biederman
[not found] ` <m1r5sywebv.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-10-20 11:58 ` Cedric Le Goater [this message]
2009-10-20 11:58 ` Cedric Le Goater
2009-10-20 12:09 ` Alexey Dobriyan
-- strict thread matches above, loose matches on Subject: below --
2009-10-20 4:13 Sukadev Bhattiprolu
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=4ADDA5EA.2060200@fr.ibm.com \
--to=clg-nmtc/0zbporqt0dzr+alfa@public.gmane.org \
--cc=adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=andrea-Vyt77T80VFVWk0Htik3J/w@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=jack-+ZI9xUNit7I@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mingo-X9Un+BFzKDI@public.gmane.org \
--cc=sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
/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.