lkml.org 
[lkml]   [2012]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 07/11] pidns: Wait in zap_pid_ns_processes until pid_ns->nr_hashed == 1
On 11/16, Eric W. Biederman wrote:
>
> @@ -216,22 +216,15 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
>
> /*
> * sys_wait4() above can't reap the TASK_DEAD children.
> - * Make sure they all go away, see __unhash_process().
> + * Make sure they all go away, see free_pid().
> */
> for (;;) {
> - bool need_wait = false;
> -
> - read_lock(&tasklist_lock);
> - if (!list_empty(&current->children)) {
> - __set_current_state(TASK_UNINTERRUPTIBLE);
> - need_wait = true;
> - }
> - read_unlock(&tasklist_lock);
> -
> - if (!need_wait)
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + if (pid_ns->nr_hashed == 1)
> break;
> schedule();
> }

I agree, the patch itself looks fine.

But, with all other changes I do not understand this part at all.

A task from the parent namespace can do setns + fork at any time
(until nr_hashed >= 0). So ->nr_hashed can be incremented again
after zap_pid_ns_processes() returns.

Or, we can sleep in TASK_UNINTERRUPTIBLE "forever" if this happens
after kill-them-all.

Could you explain why do we need to wait at all? I can be easily
wrong, but at first glance the original reason for this wait has
gone away?

Oleg.



\
 
 \ /
  Last update: 2012-12-19 20:01    [W:0.484 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site