[PATCH 07] rework prepare_ptrace_attach/finish_ptrace_attach
Roland McGrath
roland at redhat.com
Mon Aug 24 06:32:18 UTC 2009
> > 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
More information about the utrace-devel
mailing list