[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.024 / U:7.088 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site