> 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
