Messages in this thread | | | From | Roland McGrath <> | Subject | Re: [PATCH 08/10] ptrace: participate in group stop from ptrace_stop() iff the task is trapping for group stop | Date | Fri, 28 Jan 2011 13:30:09 -0800 (PST) |
| |
> A visible behavior change is increased likelihood of delayed group > stop completion if the thread group contains one or more ptraced > tasks.
I object to that difference in behavior. As I've said before, I don't think there should be any option to circumvent a group stop via ptrace. If you think otherwise, you have a hard road to convince me of it.
It was always the intent that traced tasks should participate in the group stop bookkeeping. I suspect the better line of fixes will be just to tie up the loose ends of the ptrace interactions so that all ptrace stops do the correct group_stop_count bookkeeping and notifications. If there is a group stop in progress but not yet complete, then PTRACE_CONT on a thread in the group should probably just move it from TASK_TRACED to TASK_STOPPED without resuming it at all.
Once a group stop is complete, then probably the ideal is that PTRACE_CONT would not resume a thread until a real SIGCONT cleared the job control stop condition. But it's likely that existing ptrace users have expectations contrary to that, so we'll have to see.
Thanks, Roland
| |