> I mostly agree, but I'd like to keep this helper for now. I am not sure > yet, but perhaps it will be needed if we change detach to play with > ptrace_utrace_detached_ops. This was a reason why I added the separate > helper. But let me repeat I am not sure it will be really needed.
Ok. > Or, we can change ptrace_report_signal() (or even utrace_get_signal()) > to check __fatal_signal_pending(). See my last message, that's what we really want anyway. > Yes, if utrace_get_signal() dequeues SIGKILL it doesn't report and > just returns. Right. > But, ptrace_report_signal() does: > > context->siginfo = info; > /* > * context->siginfo points to the caller's stack. > * Make sure the subsequent UTRACE_SIGNAL_REPORT clears > * ->siginfo before return from get_signal_to_deliver(). > */ > utrace_control(task, engine, UTRACE_INTERRUPT); > > this means that, even if killed, the tracee will call utrace_get_signal() > with utrace->interrupt == T. In this case UTRACE_SIGNAL_REPORT will be > reported anyway. > > Right? Ah, yes, that is right. However, my feeling is that the really right thing for the utrace API is that the new fatal_signal_pending() check will be before even this. That is, the principle is that immediately upon SIGKILL it dies as quickly as possible and skips any stops or callbacks that aren't really required to prevent confusion. That logic says we could nix report_exit too and really only keep report_death, though I think it's probably better to guarantee report_exit always gets called--but a UTRACE_STOP from there should not be obeyed, it should finish dying fast. Thanks, Roland
