> what about get_utrace_lock() ? Do we really need the EXI_DEAD check? > And this check looks "racy" too.
It is not strictly necessary any more, no. It now serves as an early unsynchronized check before taking the utrace lock, rather than as a reliable interlock. The same is now true of the check at the top of utrace_attach_task. I'm not inclined to remove them. They don't hurt now, and we'll need them back later to reimplement indirect struct utrace. > If utrace_attach_delay() fails, utrace_attach_task() returns this error. > This is right, but for example, prepare_ptrace_attach() will convert it > to EPERM? Good catch. But note that we are not really trying to review the utrace-ptrace branch right now. Thanks, Roland