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][usercr]: Ghost tasks must be detached
Date: Tue, 22 Feb 2011 11:28:41 +0100	[thread overview]
Message-ID: <20110222102841.GQ518@hawkmoon.kerlabs.com> (raw)
In-Reply-To: <20110221204058.GC14377-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>


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

On 21/02/11 12:40 -0800, Sukadev Bhattiprolu wrote:
> Louis Rilling [Louis.Rilling-aw0BnHfMbSpBDgjK7y7TUQ@public.gmane.org] wrote:
> | > But in 2.6.32 i.e RHEL5, tsk->signal is set to NULL in __exit_signal().
> | > So, I am trying to rule out the following scenario:
> | > 
> | > 	Child (may not be a ghost)			Parent
> | > 	-------------------------                       ------
> | > - exit_notify(): is EXIT_DEAD 
> | > - release_task():
> | > 	 - drops task_list_lock
> | > 	 					- itself proceeds to exit.
> | > 						- enters release_task()
> | > 						- sets own->signal = NULL
> | > 						  (in 2.6.32, __exit_signal())
> | > 
> | > - enters exit_checkpoint()
> | > - __wake_up_parent()
> | > 	access parents->signal NULL ptr
> | > 
> | > Not sure if holding task_list_lock here is needed or will help.
> | 
> | Giving my 2 cents since I've been Cc'ed.
> 
> Thanks, appreciate the input :-)
> 
> | 
> | AFAICS, holding tasklist_lock prevents __exit_signal() from setting
> | parent->signal to NULL in your back. So something like this should be safe:
> | 
> | 	read_lock(&tasklist_lock);
> | 	if (current->parent->signal)
> | 		__wake_up_parent(...);
> | 	read_unlock(&tasklist_lock);
> 
> Yes, checking the parent->signal with task_list_lock would work.
> 
> | 
> | I haven't looked at the context, but of course this also requires that some
> | get_task_struct() on current->parent has been done somewhere else before current
> | has passed __exit_signal().
> | 
> | By the way, instead of checking current->parent->signal,
> | current->parent->exit_state would look cleaner to me. current->parent is not
> | supposed to wait on ->wait_chldexit after calling do_exit(), right?
>                                                     ^^^^^^^
> 
> Hmm, do you mean exit_notify() here ?

Right, I had forgotten zap_pid_ns_processes() ;) My point was just that once
->exit_state is set (for all threads), ->signal->wait_chldexit is not used
anymore. But I'm sure that you got it right :)

Thanks,

Louis

> 
> If so, yes checking the exit_state is cleaner.
> 
> If the parent's exit_state is set, then it can't be waiting for the ghost,
> so no need to wake_up_parent(). If exit state is not set, then it is safe
> to wake_up_parent() (parent->signal would not yet have been cleared for
> instance).
> 
> The one case where a parent in do_exit() could still wait for the child is 
> the container-init which waits on wait_chldexit in do_exit() ->
> zap_pid_ns_processes() - but even in that case the __wake_up_parent()
> call would be safe.
> 
> 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: 197 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-22 10:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-11  3:35 [PATCH][usercr]: Ghost tasks must be detached Sukadev Bhattiprolu
     [not found] ` <20101211033548.GA12584-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-01-11  1:51   ` Oren Laadan
     [not found]     ` <4D2BB78A.9090701-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-02-05 18:55       ` Oren Laadan
     [not found]         ` <4D4D9D1B.3000209-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-02-05 21:40           ` Sukadev Bhattiprolu
     [not found]             ` <20110205214032.GA12944-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-05 22:02               ` Oren Laadan
     [not found]                 ` <4D4DC90B.3010103-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-02-05 22:33                   ` Oren Laadan
2011-02-09  2:09                   ` Sukadev Bhattiprolu
     [not found]                     ` <20110209020942.GA5339-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-09  3:35                       ` Oren Laadan
     [not found]                         ` <4D520B78.9020300-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-02-10  2:44                           ` Sukadev Bhattiprolu
     [not found]                             ` <20110210024430.GA23167-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-10  3:53                               ` Oren Laadan
     [not found]                                 ` <4D536154.8000900-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-02-10  6:17                                   ` Sukadev Bhattiprolu
     [not found]                                     ` <20110210061730.GA25432-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-10 14:56                                       ` Oren Laadan
     [not found]                                         ` <4D53FC9C.1050405-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-02-10 17:42                                           ` Sukadev Bhattiprolu
2011-02-16 20:10                                           ` Sukadev Bhattiprolu
     [not found]                                             ` <20110216201019.GA27698-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-17 15:21                                               ` Louis Rilling
     [not found]                                                 ` <20110217152116.GM518-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-02-21 20:40                                                   ` Sukadev Bhattiprolu
     [not found]                                                     ` <20110221204058.GC14377-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-22 10:28                                                       ` Louis Rilling [this message]
2011-02-09 12:01                       ` Louis Rilling
     [not found]                         ` <20110209120100.GD13323-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-02-09 12:18                           ` Oren Laadan
     [not found]                             ` <4D528629.7030905-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2011-02-09 12:35                               ` Louis Rilling
     [not found]                                 ` <20110209123550.GG13323-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-02-09 12:37                                   ` Louis Rilling
2011-02-09 19:02                           ` Sukadev Bhattiprolu
     [not found]                             ` <20110209190216.GA17051-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-10 10:23                               ` Louis Rilling
     [not found]                                 ` <20110210102312.GC6360-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-02-10 17:54                                   ` Sukadev Bhattiprolu
     [not found]                                     ` <20110210175409.GB1025-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-10 18:04                                       ` Louis Rilling
     [not found]                                         ` <20110210180433.GI6360-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2011-02-10 22:31                                           ` Sukadev Bhattiprolu
2011-02-25  7:58   ` Sukadev Bhattiprolu
     [not found]     ` <20110225075808.GC24361-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2011-02-25 15:46       ` Oren Laadan

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=20110222102841.GQ518@hawkmoon.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.