From: Pavel Emelyanov <xemul@parallels.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Cyrill Gorcunov <gorcunov@openvz.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Louis Rilling <louis.rilling@kerlabs.com>,
Mike Galbraith <efault@gmx.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] pidns: guarantee that the pidns init will be the last pidns process reaped
Date: Thu, 31 May 2012 14:32:51 +0400 [thread overview]
Message-ID: <4FC748D3.8050606@parallels.com> (raw)
In-Reply-To: <20120530181500.GA20130@redhat.com>
On 05/30/2012 10:15 PM, Oleg Nesterov wrote:
> From: Eric W. Biederman <ebiederm@xmission.com>
>
> Today we have a two-fold bug. Sometimes release_task on pid == 1 in a
> pid namespace can run before other processes in a pid namespace have had
> release task called. With the result that pid_ns_release_proc can be
> called before the last proc_flus_task() is done using
> upid->ns->proc_mnt, resulting in the use of a stale pointer. This same
> set of circumstances can lead to waitpid(...) returning for a processes
> started with clone(CLONE_NEWPID) before the every process in the pid
> namespace has actually exited.
>
> To fix this modify zap_pid_ns_processess wait until all other processes
> in the pid namespace have exited, even EXIT_DEAD zombies.
>
> The delay_group_leader and related tests ensure that the thread gruop
> leader will be the last thread of a process group to be reaped, or to
> become EXIT_DEAD and self reap. With the change to zap_pid_ns_processes
> we get the guarantee that pid == 1 in a pid namespace will be the last
> task that release_task is called on.
>
> With pid == 1 being the last task to pass through release_task
> pid_ns_release_proc can no longer be called too early nor can wait
> return before all of the EXIT_DEAD tasks in a pid namespace have exited.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Pavel Emelyanov <xemul@parallels.com>
next prev parent reply other threads:[~2012-05-31 10:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120530175745.GA19327@redhat.com>
2012-05-30 18:14 ` [PATCH 0/2] pidns: premature pid_ns_release_proc() fixes Oleg Nesterov
2012-05-30 18:15 ` [PATCH 1/2] pidns: guarantee that the pidns init will be the last pidns process reaped Oleg Nesterov
2012-05-31 10:32 ` Pavel Emelyanov [this message]
2012-06-13 21:52 ` Andrew Morton
2012-06-13 22:17 ` Eric W. Biederman
2012-06-14 17:20 ` Oleg Nesterov
2012-05-30 18:15 ` [PATCH 2/2] pidns: find_new_reaper() can no longer switch to init_pid_ns.child_reaper Oleg Nesterov
2012-05-31 10:33 ` Pavel Emelyanov
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=4FC748D3.8050606@parallels.com \
--to=xemul@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=efault@gmx.de \
--cc=gorcunov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=louis.rilling@kerlabs.com \
--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.