Re: [RFC PATCH 7/X] ptrace: mv task->parent ptrace_task->pt_tracer

[Oleg Nesterov <oleg@redhat.com>]

On 05/27, Roland McGrath wrote:
>
> > 		if (!exit_code)
> > 			child->exit_code = exit_code;
>
> The condition is wrong.  It's unconditional except in the "already killed"
> case that ptrace_detach() is checking for.  It never depends on the value.
> (You probably meant the inverse of this test.  But that's wrong too.
> PTRACE_CONT,0 must clear the old signal and not deliver any signal.)

This is optimization. If exit_code == 0 we do not need to fixup
->last_siginfo. Note that we have another "child->exit_code = exit_code"
below in the slow path.

> > 		if (child->exit_code == exit_code)
> > 			return;
>
> This makes no sense unless it's before setting it.

This also covers the "exit_code == 0" case. If exit_code = 0 we have
already set child->exit_code, we can return.

> > The disadvantage is, ptrace_notify() does not need this, we add the
> > little pessimization...
>
> It can check for !child->last_siginfo before lock_task_sighand().

ptrace_stop() always sets ->last_siginfo != NULL.

> > And. This change adds another dependency with arches which implement
> > their own resume.
>
> The current draft series is meant to assume arch issues are already dealt
> with before this merges.  If we need to sequence this part of it later than
> most of it, we can revisit that later before really preparing to merge it.
>
> > So. Do you think this cleanup should be done before/with this series
> > or we can do it later?
>
> Whatever you think fits best.  Right now I just want to get the rough draft
> of the series all the way to the end of the most substantive work.  Do that
> however seems most efficacious now.  We can juggle the order again later to
> ease the eventual merging.

OK, lets do this change later ;)

Oleg.