On 10/20, Roland McGrath wrote:
>
> > 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).
>
> Ugly, but correct and simple. It's only ugly when called in an error case.
I don't see why it is simple ;) But as I said, I must have a blind spot
here. Afaics it is not easy to cancel UTRACE_STOP request correctly.
> > 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;
>
> Right. That is fine as long as there are no races that can confuse it.
> I don't see any off hand.
>
> > 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.
>
> Correct (if it's in TASK_TRACED, not TASK_STOPPED). It needs to test the
> ptrace-stoppedness state in ptrace_context. You only need any
> UTRACE_STOP-related logic to counter any possible races with wakeup.
> i.e., if the stoppedness state is still left when you resume and cleared by
> the tracee's own callbacks, you would get a false positive in case the
> tracee had not been scheduled yet. Since the ptrace-stoppedness should
> never be indicated without the engine being in UTRACE_STOP state, the only
> other race is with SIGKILL wakeups. That one probably doesn't matter,
> since it's no different from the SIGKILL wakeup coming just after
> ptrace_check_attach() returns 0.
OK. I need to think about this later.
So, we have 2 known problems: this one and jctl stacked events. Both
are minor, and I doubt some test-case can notice. Especially because
the multitracing case is not possible now.
I am going to do some other changes which hopefully can reduce the
number of necessary changes outside of ptrace.c, then return to these
problems.
Oleg.
