> > And then you check whether it's really in a proper ptrace stop, see that it > > isn't, and use UTRACE_RESUME. > > So far I don't really understand to do this correctly, but OK.
I guess I'm missing something because it seems trivial to me. > ptrace_check_attach() does verify we are ptracer. If the task has > ptrace_utrace_ops engine and we are ->parent - we ptrace this task. Ok, good. In that case I think we have wide latitude to perturb the task slightly (in the "not visible to the task itself" realm) when handling any corner cases where ptrace will return an error. > Yes. I meant, perhaps it would be nice to have a "passive" method to > check if it stopped or not via utrace API. I don't see the case for that. If you want it stopped, you use UTRACE_STOP. If you care about job-control state, you can just look at its ->signal->flags yourself. If you need some unsynchronized query whether or not some other utrace engine is using UTRACE_STOP, then your engine is just not designed sensibly. You are not supposed to know or care about other engines except for the direct effects of what they are doing that you see in your own callbacks. > Yes. ptrace should use report_jctl() anyway to solve other problems > with jctl stops, but lets discuss this later. Ok. > > I wonder if we could make ->state = TASK_STOPPED|TASK_TRACED work to > > keep task_is_stopped() as a meaningful test while in UTRACE_STOP. > > Hmm. Never thought about this! looks interesting and useful to me... It sure feels cleaner than a lot of SIGNAL_STOP_STOPPED fiddling logic. But it probably has hidden complexities. Right now, it is a significant change outside the existing tracehook.h and core stuff, so it would probably complicate the subject of reviewing and merging utrace. Thanks, Roland
