On 07/27, Roland McGrath wrote:
>
> > utrace_wakeup:
> >
> > if (likely(task_is_stopped_or_traced(target))) {
> > if (target->signal->flags & SIGNAL_STOP_STOPPED)
> > target->state = TASK_STOPPED;
> > else
> > wake_up_state(target, __TASK_STOPPED | __TASK_TRACED);
> > }
>
> Looks like it should look at group_stop_count too.
Yes.
> > The code above means that utrace can't wake up the tracee if it was
> > group-stopped. This looks reasonable, but in that case I don't understand
> > what should we do if ->report_signal() returns UTRACE_SIGNAL_STOP. I mean,
> > the attached engine can stop the tracee but can't wake it up?
>
> I'm not sure I follow the question.
I meant, we can't wake up via utrace_control(),
> If you want it to
> wake up from that, you send it a SIGCONT.
Yes sure.
> > if (task_is_stopped(child)) {
> > spin_lock_irq(&child->sighand->siglock);
> > child->signal->flags &= ~SIGNAL_STOP_STOPPED;
> > spin_unlock_irq(&child->sighand->siglock);
> > }
>
> All this is bug-compatibility with traditional ptrace where it uses
> wake_up_process() unconditionally without regard to all the bookkeeping.
OK. I guess this answers my "do you really want a user-visible change"
question in another thread.
> Probably the right thing to will be to fix the upstream ptrace semantics
> and figure out any userland issues with that, and then we won't have any
> kludge like this for utrace-based ptrace.
Oh. I bet, if we change the current behaviour, we will have bug-reports ;)
Oleg.
