Messages in this thread | | | From | (Eric W. Biederman) | Date | Wed, 16 May 2012 13:54:17 -0700 | Subject | Re: [PATCH 2/3] pidns: Guarantee that the pidns init will be the last pidns process reaped. |
| |
Oleg Nesterov <oleg@redhat.com> 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
| |