Messages in this thread | | | Date | Tue, 8 May 2012 15:50:20 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 2/3] pidns: Guarantee that the pidns init will be the last pidns process reaped. |
| |
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?
> > ... >
| |