> another nasty case is report_exit(). Even if we fix the discussed problems > with explicit/implicit SIGKILL's. We shouldn't afaics skip this report if > the tracee was killed by execing sub-thread.
Yes, that's a good point. The rationale for true SIGKILL being "more direct" (i.e. skipping events) doesn't necessarily apply at all to the exec case. (We should still get rid of that case involving the fake SIGKILL as it does today for other reasons, but that's not for now.) What I'd had in mind was skipping the exit report too, but I'd overlooked that __fatal_signal_pending() will no longer catch there. But the exec case muddles this as an API choice, regardless of implementation details. > Both can be fixed if we add spin_unlock_wait() before REPORT(). But imho > it would be safer if we start with spin_unlock_wait() in utrace_stop(), > perhaps there is something else to consider. I was only musing about the API choice. If we keep today's API where those reporting passes will still be made after a SIGKILL (but effectively ignore UTRACE_STOP), then synchronizing only in utrace_stop and utrace_finish_jctl is clearly right. Thanks, Roland
