Linux Container Development
 help / color / mirror / Atom feed
From: Louis Rilling <Louis.Rilling-aw0BnHfMbSpBDgjK7y7TUQ@public.gmane.org>
To: Sukadev Bhattiprolu
	<sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: [PATCH][cr]: Fix ghost task bug
Date: Sat, 26 Feb 2011 14:54:32 +0100	[thread overview]
Message-ID: <20110226135431.GA3251@kerlabs.com> (raw)
In-Reply-To: <20110225190132.GA31300-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 4182 bytes --]

On Fri, Feb 25, 2011 at 11:01:32AM -0800, Sukadev Bhattiprolu wrote:
> 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).

I think I see now. The point is that ->exit_signal = -1 is only meant to work
correctly for sub-threads, which the parent does not need to wait for. IOW, the
notion of detached task is only implemented for sub-threads.

IIUC, setting ->exit_signal to -1 is only used here to let exit_notify() set
->exit_state to EXIT_DEAD, right? Otherwise, setting ->exit_signal to 0 and
letting do_notify_parent() proceed for ghost tasks would have be sufficient I
guess (provided that the confusion between ghost tasks and zombies could be
easily avoided in do_notify_parent()).

Then I agree that the proposed patch looks like a reasonably simple approach.

Thanks for the explanation,

Louis

> 
> Sukadev
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linux-foundation.org/mailman/listinfo/containers

-- 
Dr Louis Rilling			Kerlabs
Skype: louis.rilling			Batiment Germanium
Phone: (+33|0) 6 80 89 08 23		80 avenue des Buttes de Coesmes
http://www.kerlabs.com/			35700 Rennes

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

  parent reply	other threads:[~2011-02-26 13:54 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
     [not found]         ` <20110225190132.GA31300-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-26 13:54           ` Louis Rilling [this message]
     [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=20110226135431.GA3251@kerlabs.com \
    --to=louis.rilling-aw0bnhfmbspbdgjk7y7tuq@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox