lkml.org 
[lkml]   [2010]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 13/16] ptrace: reorganize __ptrace_unlink() and ptrace_untrace()
    A bit off-topic note,

    On 12/06, Tejun Heo wrote:
    >
    > -static void ptrace_untrace(struct task_struct *child)
    > +void __ptrace_unlink(struct task_struct *child)
    > {
    > + struct signal_struct *sig = child->signal;
    > +
    > + BUG_ON(!child->ptrace);
    > +
    > spin_lock(&child->sighand->siglock);
    > +
    > if (task_is_traced(child)) {
    > /*
    > * If group stop is completed or in progress, it should
    > * participate in the group stop. Set GROUP_STOP_PENDING
    > * before kicking it.
    > */
    > - if (child->signal->flags & SIGNAL_STOP_STOPPED ||
    > - child->signal->group_stop_count)
    > + if (sig->flags & SIGNAL_STOP_STOPPED || sig->group_stop_count)
    > child->group_stop |= GROUP_STOP_PENDING;
    > signal_wake_up(child, 1);

    OK. Of course, I do not blame this patch, this mimics the current
    behaviour.

    But, afaics, this is not exactly right in the long term. Suppose
    that SIGNAL_STOP_STOPPED is set but the tracee is running (this can
    happen if, say, debugger resumes the tracee and exits). In this case,
    I think this thread should be stopped too.

    IIRC, I already tried to do this, but the patch (or idea) was nacked
    because it means another user-visible change. However, if we want to
    really fix things, we should fix this case too. If SIGNAL_STOP_STOPPED
    is set, there should be no running threads after detach.

    Or. We can change the rules for ptrace_resume(), more on this later.

    Oleg.



    \
     
     \ /
      Last update: 2010-12-20 19:25    [W:0.022 / U:123.180 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site