Re: [PATCH 2/3] pidns: Guarantee that the pidns init will be the last pidns process reaped.

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 06 May 2012 17:35:02 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:

> 
> This change extends the thread group zombie leader logic to work for pid
> namespaces.  The task with pid 1 is declared the pid namespace leader.
> A pid namespace with no more processes is detected by observing that the
> init task is a zombie in an empty thread group, and the the init task
> has no children.
> 
> Instead of moving lingering EXIT_DEAD tasks off of init's ->children
> list we now block init from exiting until those children have self
> reaped and have removed themselves.  Which guarantees that the init task
> is the last task in a pid namespace to be reaped.
> 
> ...
>
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -164,6 +164,16 @@ static void delayed_put_task_struct(struct rcu_head *rhp)
>  	put_task_struct(tsk);
>  }
>  
> +static bool pidns_leader(struct task_struct *tsk)
> +{
> +	return is_child_reaper(task_pid(tsk));
> +}
> +
> +static bool delay_pidns_leader(struct task_struct *tsk)
> +{
> +	return pidns_leader(tsk) &&
> +	       (!thread_group_empty(tsk) || !list_empty(&tsk->children));
> +}

The code would be significantly easier to understand if the above two
functions were documented.

What is the significance of pidns leadership, and why might callers
want to know this?

delay_pidns_leader() seems poorly named, which doesn't help.  I guess
it's trying to say "should delay the pidns leader".  But even then, it
doesn't describe *why* the leader should be delayed.

Have a think about it, please?

>
> ...
>