[lkml]   [2011]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 08/10] ptrace: participate in group stop from ptrace_stop() iff the task is trapping for group stop
> 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.


 \ /
  Last update: 2011-01-28 22:33    [W:0.223 / U:19.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site