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

[Eric W. Biederman]

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/