From: ebiederm@xmission.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@redhat.com>
Cc: Caj Larsson <caj@omnicloud.com>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Zombie stuck in zap_pid_ns_processes()
Date: Tue, 26 Mar 2013 03:29:05 -0700 [thread overview]
Message-ID: <87fvzia1zi.fsf@xmission.com> (raw)
In-Reply-To: <20130324132047.GA13419@redhat.com> (Oleg Nesterov's message of "Sun, 24 Mar 2013 14:20:47 +0100")
Oleg Nesterov <oleg@redhat.com> writes:
> On 03/24, Eric W. Biederman wrote:
>>
>> --- a/kernel/pid_namespace.c
>> +++ b/kernel/pid_namespace.c
>> @@ -181,6 +181,7 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
>> int nr;
>> int rc;
>> struct task_struct *task, *me = current;
>> + int init_pids = task_pid_vnr(me) == 1 ? 1 : 2;
> ^^^^^^^^^^^^^^^^^^^^^
>
> Ah, mt-init.
>
> perhaps thread_group_leader(me) would be more clean/simple,
> but I won't insist of course.
It is. Thanks, I was going to follow the reaper but that changes when the
initial thread exits...
Here is my final version of the patch, that I will push shortly.
Eric
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Tue, 26 Mar 2013 02:27:11 -0700
Subject: [PATCH] pid: Handle the exit of a multi-threaded init.
When a multi-threaded init exits and the initial thread is not the
last thread to exit the initial thread hangs around as a zombie
until the last thread exits. In that case zap_pid_ns_processes
needs to wait until there are only 2 hashed pids in the pid
namespace not one.
v2. Replace thread_pid_vnr(me) == 1 with the test thread_group_leader(me)
as suggested by Oleg.
Cc: stable@vger.kernel.org
Cc: Oleg Nesterov <oleg@redhat.com>
Reported-by: Caj Larsson <caj@omnicloud.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
kernel/pid_namespace.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index c1c3dc1..bea15bd 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -181,6 +181,7 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
int nr;
int rc;
struct task_struct *task, *me = current;
+ int init_pids = thread_group_leader(me) ? 1 : 2;
/* Don't allow any more processes into the pid namespace */
disable_pid_allocation(pid_ns);
@@ -230,7 +231,7 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
*/
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (pid_ns->nr_hashed == 1)
+ if (pid_ns->nr_hashed == init_pids)
break;
schedule();
}
--
1.7.5.4
prev parent reply other threads:[~2013-03-26 10:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 8:43 Zombie stuck in zap_pid_ns_processes() Caj Larsson
2013-03-24 11:04 ` Eric W. Biederman
2013-03-24 13:20 ` Oleg Nesterov
2013-03-26 10:29 ` Eric W. Biederman [this message]
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=87fvzia1zi.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=caj@omnicloud.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.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.