Q: utrace && ptrace_check_attach()

[Roland McGrath]

> I meant ptrace_resume()->task_is_stopped() check in ptrace_utrace.patch.

Oh.  I think that was an attempt at ptrace bug-compatibility.
Like I keep saying, don't take any code in that patch seriously.

> Yes, the whole-process stop will be delayed until the debugger
> wakes up the tracee and it sees signal_pending().

I don't think we want this.

> Not nice, agreed, but probably not too bad. The debugger doesn't
> really care. As for real parent, it will be confused in any case.

No, it needn't be.

> It can't assume the whole process is really stopped, debugger
> can wake up a thread at any moment.

No, it can't.  That's what "get the bookkeeping right" means.
It the debugger uses UTRACE_RESUME et al, then that thread moves
from TASK_TRACED into TASK_STOPPED and still never runs.

> > The bookkeeping should ensure that when a TASK_TRACED thread was
> > counted as stopped,
> 
> But we can't know if it was already counted or not. 

Sure we can.  The group_stop_count is set by the stop-instigator while it
holds siglock and checks every thread's ->state.  All transitions into or
out of TASK_TRACED are done holding the siglock.  When you take siglock and
see there is a stop in progress, then you know the thread's TASK_TRACED was
counted as stopped in setting up that stop.

> And note that utrace_stop() doesn't set SIGNAL_STOP_STOPPED and doesn't
> notify if ->group_stop_count becomes 0.

We can fix this.

> > then utrace never wakes it up but instead puts it
> > in TASK_STOPPED
> 
> only if group-stop is already completed.

Or in progress.

> Or we can ignore all these problems, there are not new.

No, let's get it right for a change! ;-)

> So. Let's change utrace_do_stop() to set TASK_TRACED,

I like that direction.

> Or do you think it is better to add tracehook_finish_stop() helper which is
> called by do_signal_stop() to clear ->stopped ?

Let's do it however makes the code taken all together come out cleanest.
>From what you said before, it sounds like tracehook_finish_stop() would
help with that.

> As you pointed out we can remove ->stopped, but I am not sure we should do
> this now.

Sure, we can take it one step at a time.  Once we have cleaned up all the
stop handling, we can see what this flag is still doing for us.

> BTW, can't finish_utrace_stop() check utrace->stopped lockless?

You tell me!


Thanks,
Roland