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(¤t->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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
