Re: [PATCH 3/3] ptrace_untrace: fix the SIGNAL_STOP_STOPPED check

[Roland McGrath]

Yes, I believe this is correct.  It matches the flip side of the
bookkeeping where we adjust group_stop_count when going into TASK_TRACED
(ptrace_stop).  I think it warrants a comment with your change, saying that
treating group_stop_count as "we should be already stopped" is consistent
with decrementing an active group_stop_count when we enter TASK_TRACED.

> 	- if the process/thread was traced, SIGNAL_STOP_STOPPED
> 	  does not necessary means this thread group is stopped.
>
> 	- ptrace breaks the bookkeeping of ->group_stop_count.

SIGNAL_STOP_STOPPED is only set when all live threads in the group are in
either TASK_TRACED or TASK_STOPPED.  PTRACE_DETACH respects this and this
it stopped.  However, PTRACE_CONT et al (ptrace_resume) do not respect it
and can resume an individual thread regardless of SIGNAL_STOP_STOPPED.
That's what you mean here, right?

Doing that without a SIGCONT having been generated is an anomalous way for
a debugger to behave, since it's going to eat the effects of the job
control stop.  But who knows that things they do, so this could be sticky
to fix so that SIGNAL_STOP_STOPPED really means all stopped.

> (the comment above ptrace_untrace() doesn't look exactly right too).

How so?


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/