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

From: Eric W. Biederman
Date: Wed May 16 2012 - 16:54:25 EST


Oleg Nesterov <oleg@xxxxxxxxxx> writes:

> Eric, sorry for the huge delay, I was on vacation when you sent this patch...
>
> On 05/06, Eric W. Biederman wrote:
>>
>> @@ -798,6 +815,12 @@ static void forget_original_parent(struct task_struct *father)
>> exit_ptrace(father);
>> reaper = find_new_reaper(father);
>>
>> + /* Return immediately if we aren't going to reparent anything */
>> + if (unlikely(reaper == father)) {
>> + write_unlock_irq(&tasklist_lock);
>> + return;
>> + }
>
> I was confused by the comment. Afaics, it is not that "we aren't
> going to reparent", we need this change because we can't "reparent"
> to the same thread, list_for_each_entry_safe() below can never stop.
> But this is off-topic...

True. We will get stuck if we try to reparent to the same process.

> Hmm. I don't think the patch is 100% correct. Afaics, this needs more
> delay_pidns_leader() checks.
>
> For example. Suppose we have a CLONE_NEWPID zombie I, it has an
> EXIT_DEAD child D so delay_pidns_leader(I) == T.
>
> Now suppose that I->real_parent exits, lets denote this task as P.
>
> Suppose that P->real_parent ignores SIGCHLD.
>
> In this case P will do release_task(I) prematurely. And worse, when
> D finally does realease_task(D) it will do realease_task(I) again.

Good point. I will fix that and post a patch shortly. It doesn't
need a full delay_pidns_leader test just a test for children.

In looking for any other weird corner case bugs I am noticing that
I don't think I handled the case of a ptraced init quite right.
I don't understand the change signaling semantics when the
ptracer is our parent.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/