From: Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>,
Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: [PATCH][cr]: Fix ghost task bug
Date: Fri, 25 Feb 2011 11:01:32 -0800 [thread overview]
Message-ID: <20110225190132.GA31300@us.ibm.com> (raw)
In-Reply-To: <20110225115507.GD3915-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
Louis Rilling [Louis.Rilling-aw0BnHfMbSpBDgjK7y7TUQ@public.gmane.org] wrote:
| On 24/02/11 23:55 -0800, Sukadev Bhattiprolu wrote:
| >
| > diff --git a/kernel/checkpoint/restart.c b/kernel/checkpoint/restart.c
| > index b0ea8ec..8ecc052 100644
| > --- a/kernel/checkpoint/restart.c
| > +++ b/kernel/checkpoint/restart.c
| > @@ -972,6 +972,7 @@ static int do_ghost_task(void)
| > if (ret < 0)
| > ckpt_err(ctx, ret, "ghost restart failed\n");
| >
| > + current->exit_signal = -1;
|
| Setting ->exit_signal outside of tasklist_lock makes me nervous. All other
| places that change ->exit_signal hold write_lock_irq(&tasklist_lock), and
| eligibile_child() (for an instance of a reader being another task) holds
| read_lock(&tasklist_lock). But maybe this does not matter for ghost tasks.
|
Yes, an earlier version had the write_lock(&tasklist_lock). Will add it
back.
| > restore_debug_exit(ctx);
| > ckpt_ctx_put(ctx);
| > do_exit(0);
| > @@ -1465,7 +1466,22 @@ void exit_checkpoint(struct task_struct *tsk)
| > /* restarting zombies will activate next task in restart */
| > if (tsk->flags & PF_RESTARTING) {
| > BUG_ON(ctx->active_pid == -1);
| > +
| > + /*
| > + * if we are a "ghost" task, that was terminated by the
| > + * container-init (from zap_pid_ns_processes()), we should
| > + * wake up the parent since we are now a detached process.
| > + */
| > + read_lock_irq(&tasklist_lock);
|
| read_lock() is enough. tasklist_lock is never taken for write from IRQs or
| softIRQs.
|
| > + if (tsk->exit_state == EXIT_DEAD && !tsk->parent->exit_state) {
| > + ckpt_debug("[%d, %s]: exit_checkpoint(): notifying "
| > + "parent\n", tsk->pid, tsk->comm);
| > + __wake_up_parent(tsk, tsk->parent);
| > + }
| > + read_unlock_irq(&tasklist_lock);
|
| Looking at this closer, I wonder if this wakeup logic should be called from
| do_ghost_task(), right after setting ->exit_signal. This way there would be no
| need for a tricky condition to recognize ghost tasks, and (I think) this is
| closer to the other cases changing ->exit_signal (reparent_leader() and
| exit_notify()).
Yes, we tried the following in the earlier version.
void ghost_auto_reapable()
{
write_lock(&tasklist_lock);
current->exit_signal = -1;
__wake_up_parent(current, current->parent);
write_unlock(&tasklist_lock);
}
And called this from do_ghost_task(). But with this, the parent could
wake up, find that it still has an eligible child (the ghost) to wait
for, and go back to waiting before the ghost enters the EXIT_DEAD state.
And so we would lose the wake up.
(zap_pid_ns_processes() passes the __WALL so the ghost would be considered
an eligible child).
Sukadev
next prev parent reply other threads:[~2011-02-25 19:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-25 7:55 [PATCH][cr]: Fix ghost task bug Sukadev Bhattiprolu
[not found] ` <20110225075552.GB24361-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-25 11:55 ` Louis Rilling
[not found] ` <20110225115507.GD3915-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-02-25 19:01 ` Sukadev Bhattiprolu [this message]
[not found] ` <20110225190132.GA31300-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-26 13:54 ` Louis Rilling
[not found] ` <20110226135431.GA3251-aw0BnHfMbSpBDgjK7y7TUQ@public.gmane.org>
2011-02-28 14:43 ` Oren Laadan
[not found] ` <4D6BB499.7050602-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-02-28 15:09 ` Louis Rilling
[not found] ` <20110228150942.GD18970-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-02-28 22:10 ` Oren Laadan
[not found] ` <4D6C1D58.5060400-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-03-01 15:31 ` Louis Rilling
[not found] ` <20110301153105.GD4410-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-03-03 15:38 ` Oren Laadan
[not found] ` <4D6FB5D9.8010002-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-03-03 16:35 ` Louis Rilling
[not found] ` <20110303163531.GO21429-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-03-04 16:07 ` Oren Laadan
[not found] ` <4D710E37.8000109-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-03-04 17:29 ` Louis Rilling
[not found] ` <20110304172914.GE3543-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-03-26 2:14 ` Oren Laadan
[not found] ` <4D8D4BE9.8010605-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-03-26 16:06 ` Louis Rilling
[not found] ` <20110326160607.GA18492-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-03-27 3:17 ` Oren Laadan
[not found] ` <4D8EAC5A.2080604-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-03-28 15:24 ` Louis Rilling
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=20110225190132.GA31300@us.ibm.com \
--to=sukadev-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=orenl-eQaUEPhvms7ENvBUuze7eA@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.