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

[Roland McGrath]

> 		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.)

> 		if (child->exit_code == exit_code)
> 			return;

This makes no sense unless it's before setting it.

> 		if (lock_task_sighand(child, &flags)) {
> 			siginfo_t *info = child->last_siginfo;
[...]
> And ptrace_resume/ptrace_detach should use ptrace_set_exit_code()
> instead of child->exit_code = data.

Right.

> 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().

> 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.


Thanks,
Roland
--
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/