In any event callback, the event task passed as an argument is the task that's making the call. So you are making those utrace_* calls on current.
utrace_barrier checks for target==current and does a short-circuit return. So it's a harmless no-op that always returns zero. But it really doesn't make sense to call it. utrace_set_events returns -EINPROGRESS to indicate that a callback is still in progress. When you call it from the callback function, no matter how many times or how long you wait inside that function, of course that callback is still in progress! I had forgotten to add a short-circuit check to utrace_set_events. I've added it now, so it will return 0 instead of -EINPROGRESS when called on current. Note that utrace_control on current can still return -EINPROGRESS. I didn't add any special exclusion for that. This seems about right, since current is indeed not yet stopped or detached while you make the call. (And it seems right to give a slightly funny indication, since someone calling utrace_control from inside a callback really should just use the callback return value instead.) (In the old utrace API, there was one exception. utrace_set_flags on an already-quiescent target thread could itself make the report_quiesce callback. In the new API, that never happens--all event callbacks are indeed always made for current on current by current.) BTW, the old API's UTRACE_ACTION_NEWSTATE never let you do something equivalent to utrace_set_events, only something equivalent to the enum utrace_resume_action part of the return value (or said another way, equivalent to utrace_control). You always had to call utrace_set_flags to change the event mask. Thanks, Roland
