> > 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. > > Because the tracee must not dequeue and handle this SIGSTOP until it sees > UTRACE_EVENT_SIGNAL_ALL in ->utrace_flags.
Right. utrace_set_events() sets ->utrace_flags while holding utrace->lock. Then send_sig() queues the signal while holding siglock. Are the barriers implicit in those locks not enough to guarantee that ->utrace_flags updates are done by the time siglock is released, in the view of the other CPU that then acquires siglock before reading ->utrace_flags (tracehook_get_signal)? > Yes, ->ptrace should die. But we can't kill it right now. (I mean, I don't > see how can we kill it before we have a more or less working ptrace code). Ok. > Until we kill it, ptrace_attach pathes should > > - set PT_PTRACED for task_ptrace() callers in exit/signal/etc.c You mean the wait and do_notify_parent* paths. Ok, it needs something outside utrace proper as the mark for these, and it might as well remain this for now. > - check it to avoid the races with another tracer doing detach, > iow simply to prevent __ptrace_link() before __ptrace_unlink(). I remain skeptical that this is a clean way to do things in the long run. But ok. Thanks, Roland
