Re: [PATCH 0/2] exit/pid_ns: comments + simple fix

[ebiederm@xmission.com (Eric W. Biederman)]

Oleg Nesterov <oleg@redhat.com> writes:

> Eric, Pavel, could you review 1/2 ? (documentation only). It is based on the
> code inspection, I didn't bother to verify that my understanding matches the
> reality ;)
>
> On 11/20, Oleg Nesterov wrote:
>>
>>
>> Probably this is not the last series... in particular it seems that we
>> have some problems with sys_setns() in this area, but I need to recheck.
>
> So far only the documentation fix. I'll write another email (hopefully with the
> patch), afaics at least setns() doesn't play well with PR_SET_CHILD_SUBREAPER.
>
> Contrary to what I thought zap_pid_ns_processes() looks fine, but it seems only
> by accident. Unless I am totally confused, wait for "nr_hashed == init_pids"
> could be removed after 0a01f2cc390e10633a "pidns: Make the pidns proc mount/
> umount logic obvious". However, now that setns() + fork() can inject a task
> into a child namespace, we need this code again for another reason.
>
> I _think_ we can actually remove it and simplify free_pid() as well, but lets
> discuss this later and fix the wrong/confusing documentation first.

At the very least there is the issue of rusage being wrong if we allow
the init process to be reaped before all of it's children are reaped.

There is also a huge level of weird non-intuitive behavior that would
require some substantial benefits to justify an optimization of letting
a child exist longer than init.

Eric


> 2/2 looks "obviously correct", but I'll appreciate your review anyway.
>
> Oleg.
>
>  kernel/pid.c           |    7 +++----
>  kernel/pid_namespace.c |   23 +++++++++++++++++++----
>  2 files changed, 22 insertions(+), 8 deletions(-)