> finish_utrace_stop() can check ->stopped lockless. It was set by us, > we can't miss it.
We enter utrace_stop() for some stop. Either then or later, a group jctl stop finishes and sets SIGNAL_STOP_STOPPED. Later, utrace_wakeup() sees that and we switch to TASK_STOPPED after clearing ->stopped. We stay in jctl stop for a few days. Some new debugger comes along with utrace_control(,,UTRACE_STOP) and utrace_do_stop() switches us to TASK_TRACED after setting ->stopped. Meanwhile, SIGCONT is coming along and clearing SIGNAL_STOP_STOPPED (sibling threads run again, etc.). Now the debugger calls utrace_control(,,UTRACE_RESUME), so utrace_wakeup clears ->stopped and wakes us up. Now ->stopped was just an instant ago set and then cleared on the other CPU and we are running. Are we really sure that we see it as clear rather than set? (I think there is also a racier version without jctl stops at all, just where utrace_wakeup+utrace_do_stop+utrace_wakeup all came and went before we actually got scheduled.) I might be overlooking some interlock that covers this. I put the patch in, anyway. But I think that I can even worry about this is a good indicator that we'd probably be happier if we can indeed get rid of ->stopped altogether. Thanks, Roland
