Re: [patch] ptrace-fix-2.5.33-A1

[OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>]

Daniel Jacobowitz <dan@debian.org> writes:

> > 	 * Search them and reparent children.
> > 	 */
> > 	list_for_each(_p, &father->children) {
> > 		p = list_entry(_p,struct task_struct,sibling);
> > 		reparent_thread(p, reaper, child_reaper);
> > 	}
> > 
> > Looks like that tracer deprive a process from real parent.
> 
> Oh - when the tracer exits the original parent may be corrupted, you
> mean?  I guess you're right.  But I've made so many changes to this bit
> of code that I'd like to wait until it settles before we fix this -
> it's not a new problem.

Yes, this isn't new problem. However, since other place may be
affected by this, I think should fix this first.

> > 	list_for_each(_p, &father->ptrace_children) {
> > 		p = list_entry(_p,struct task_struct,ptrace_list);
> > 		reparent_thread(p, reaper, child_reaper);
> > 	}
> > 
> > Thread group makes the child which links both ->children and
> > ->ptrace_children.
> 
> I don't understand what you mean.

Sorry, forget this.

> > >  {
> > > -	ptrace_unlink(p);
> > > -	list_del_init(&p->sibling);
> > > -	p->ptrace = 0;
> > > +	/* If we were tracing the thread, release it; otherwise preserve the
> > > +	   ptrace links.  */
> > > +	if (unlikely(traced)) {
> > > +		task_t *trace_task = p->parent;
> > > +		__ptrace_unlink(p);
> > > +		p->ptrace = 1;
> > 
> > Unexpected change of ptrace flag.
> 
> I should've caught that, I actually use the ptrace flags here.  But the
> code that uses them is suffering some other BUG() right now.

I forgot I say another point. This path shouldn't send signal to
parent.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>