All of lore.kernel.org
 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 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.