utrace-ptrace && ptrace_check_attach()

[Oleg Nesterov]

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.