[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