On 10/15, Roland McGrath wrote:
>
> > > 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.
Most probably it is me who missed something. Let me think about this
a bit later, when I will change this code.
> > 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.
But ptrace_check_attach() needs the tracee to be already stopped.
A bit ugly to ask the tracee to stop via UTRACE_STOP and then resume
it if it was not already stopped. And I don't even understand how to
do this correctly. (but again, I'll try to think later).
Apart from utrace_prepare_examine()->wait_task_inactive() and security
checks, ptrace_check_attach() should do something like
if (!task_stop_or_traced())
FAIL;
if (SIGNAL_STOP_STOPPED || // JCTL stop
get_stop_event()) { // it was stopped by us
... OK. s/STOPPED/TRACED/ and proceed ..
}
FAIL;
> 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.
Not sure. Suppose the tracer does PTRACE_SYSCALL and the tracee spins in
user-mode. Another engine stops the tracee. In this case any ptrace()
request should fail despite the fact the tracee is STOPPED or TRACED.
Yes/No ?
> > > 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.
Yes! agreed.
Oleg.
