[PATCH 07] rework prepare_ptrace_attach/finish_ptrace_attach

[Roland McGrath]

> Note that I don't really understand why I am worried ;)

Nameless fears are the most effective ones!

> C recieves a signal, notices task_utrace_flags(), calls utrace_get_signal(),
> dequeues the signal, calls E->ops->ptrace_report_signal() which returns
> UTRACE_STOP.

Ah, right.  The important point is it returns UTRACE_SIGNAL_IGN|UTRACE_STOP.

I overlooked this case, or perhaps I was wrongly thinking that it used
UTRACE_SIGNAL_HOLD.  (It doesn't and can't, because it needs to distinguish
the signal it already reported from a new one, and also because an
unrelated new one with a different (lower) signal number could be dequeued
first on the second round.)

An implicit detach (i.e. exit_ptrace) must act like a PTRACE_DETACH,signr
for the last-reported signal.  In old ptrace, that is implicit just in the
->exit_code value left behind and picked up on resume.

Your implementation of this can probably just use the same method as for a
real PTRACE_DETACH,signr.  Just pick up last_siginfo->si_signo and use it.

> In short. Perhaps I missed something, but I think it would be "safer" if
> ptrace_attach() did utrace_set_events() after setting PT_PTRACED, but this
> is not possible because attach sends SIGSTOP. [...]

I don't really understand why the SIGSTOP is your concern.  
No matter what, you send that last, after ptrace is wired up to catch it.

> Hmm. Strange, but I didn't think of another option...
> 
> ptrace_attach_task() can check ->ptrace == 0 ! Something like

Sorry, I've lost track of what this flag (that really shouldn't exist at
all) means in your version that's distinct from whether you have the
ptrace_utrace_ops engine attached.


Thanks,
Roland