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    [from the cache]
©2003-2011 Jasper Spaans