> 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

Reply via email to