From: "Serge E. Hallyn" <serge@hallyn.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>,
linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH] Make sure to wake reaper
Date: Fri, 30 Aug 2013 14:42:33 +0000 [thread overview]
Message-ID: <20130830144232.GA18281@mail.hallyn.com> (raw)
In-Reply-To: <87mwo0xb9p.fsf@xmission.com>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Serge Hallyn <serge.hallyn@ubuntu.com> writes:
>
> > Since commit af4b8a83add95ef40716401395b44a1b579965f4 it's been
> > possible to get into a situation where a pidns reaper is
> > <defunct>, reparented to host pid 1, but never reaped. How to
> > reproduce this is documented at
> >
> > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526
> > (and see
> > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526/comments/13)
> > In short, run repeated starts of a container whose init is
> >
> > Process.exit(0);
> >
> > sysrq-t when such a task is playing zombie shows:
> >
> > [ 131.132978] init x ffff88011fc14580 0 2084 2039 0x00000000
> > [ 131.132978] ffff880116e89ea8 0000000000000002 ffff880116e89fd8 0000000000014580
> > [ 131.132978] ffff880116e89fd8 0000000000014580 ffff8801172a0000 ffff8801172a0000
> > [ 131.132978] ffff8801172a0630 ffff88011729fff0 ffff880116e14650 ffff88011729fff0
> > [ 131.132978] Call Trace:
> > [ 131.132978] [<ffffffff816f6159>] schedule+0x29/0x70
> > [ 131.132978] [<ffffffff81064591>] do_exit+0x6e1/0xa40
> > [ 131.132978] [<ffffffff81071eae>] ? signal_wake_up_state+0x1e/0x30
> > [ 131.132978] [<ffffffff8106496f>] do_group_exit+0x3f/0xa0
> > [ 131.132978] [<ffffffff810649e4>] SyS_exit_group+0x14/0x20
> > [ 131.132978] [<ffffffff8170102f>] tracesys+0xe1/0xe6
> >
> > Further debugging showed that every time this happened, zap_pid_ns_processes()
> > started with nr_hashed being 3, while we were expecting it to drop to 2.
> > Any time it didn't happen, nr_hashed was 1 or 2. So the reaper was
> > waiting for nr_hashed to become 2, but free_pid() only wakes the reaper
> > if nr_hashed hits 1. This patch makes free_pid() wake the reaper any
> > time the reaper is PF_EXITING, to force it to re-test the
> > pidns->nr_hashed = init_pids test. Note that this is more like what
> > __unhash_process() used to do before
> > af4b8a83add95ef40716401395b44a1b579965f4.
> >
> > Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> > ---
> > kernel/pid.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/kernel/pid.c b/kernel/pid.c
> > index 0db3e79..6b312c4 100644
> > --- a/kernel/pid.c
> > +++ b/kernel/pid.c
> > @@ -274,6 +274,10 @@ void free_pid(struct pid *pid)
> > case 0:
> > schedule_work(&ns->proc_work);
> > break;
> > + default:
> > + if (ns->child_reaper->flags & PF_EXITING)
> > + wake_up_process(ns->child_reaper);
> > + break;
> > }
> > }
> > spin_unlock_irqrestore(&pidmap_lock, flags);
>
> qSo I think the change that we actually want is just to send a wake-up
> when we have two pids in the pid namespace as well as one pid.
>
> - That can send one extraneous wake-up but that is relatively harmless.
> - We can detect the condition race free.
> - With only two pids remaining we are guaranteed that which ever task is
> the child_reaper will persist through zap_pid_ns_processes.
>
> There are 3 cases.
> init-tgleader other -- Single threaded init so of course we won't free the task
> init-tgleader-dead init-thread -- The last living init thread will call zap_pid_ns_processes.
> init-tgleader init-thread -- An init with two living threads child_reaper must be the init thread group leader
>
> Which means at the cost of an extra wake-up we are guaranteed not to
> have races.
>
> Serge does that look good to you?
Yeah, I haven't reproduced the defunct tasks with this patch.
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Tested-by: Serge Hallyn <serge.hallyn@canonical.com>
thanks,
-serge
>
> Eric
>
>
>
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 17755ae..ab75add 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -265,6 +265,7 @@ void free_pid(struct pid *pid)
> struct pid_namespace *ns = upid->ns;
> hlist_del_rcu(&upid->pid_chain);
> switch(--ns->nr_hashed) {
> + case 2:
> case 1:
> /* When all that is left in the pid namespace
> * is the reaper wake up the reaper. The reaper
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2013-08-30 14:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-29 21:11 [PATCH] Make sure to wake reaper Serge Hallyn
2013-08-29 22:08 ` Eric W. Biederman
2013-08-30 0:39 ` Eric W. Biederman
2013-08-30 1:10 ` Serge E. Hallyn
2013-08-30 5:07 ` Eric W. Biederman
2013-08-30 12:46 ` Serge E. Hallyn
2013-08-30 14:42 ` Serge E. Hallyn [this message]
2013-08-31 0:30 ` [REVIEW][PATCH] pidns: Fix hang in zap_pid_ns_processes by sending a potentially extra wakeup Eric W. Biederman
2013-09-08 17:56 ` Oleg Nesterov
2013-09-08 18:01 ` free_pid() && PIDNS_HASH_ADDING Oleg Nesterov
2013-09-08 21:25 ` Eric W. Biederman
2013-09-09 15:15 ` Oleg Nesterov
2013-09-09 17:54 ` Eric W. Biederman
2013-09-10 14:01 ` [PATCH 0/1] pidns: fix free_pid() to handle the first fork failure Oleg Nesterov
2013-09-10 14:01 ` [PATCH 1/1] " Oleg Nesterov
[not found] ` <CALkWK0kSBrN-ZHG0CEWwvjYQ86ArJtDmbKqJR_6f3_ZTN6xJQQ@mail.gmail.com>
2013-09-09 0:12 ` [REVIEW][PATCH] pidns: Fix hang in zap_pid_ns_processes by sending a potentially extra wakeup Eric W. Biederman
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=20130830144232.GA18281@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=serge.hallyn@ubuntu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox