This was copy-and-pasted from the old code. Shouldn't we rely use
UTRACE_SIGNAL_HOLD instead ?
Perhaps so, but I'd rather leave it alone for now. The send_sig_info path
has various other checks that could be relevant to the kludgey old ptrace
semantics for this arcane case. Fresh
I think ptrace_report_signal() is mostly finished.
Unlike vanilla kernel, the tracer fixups the context of -siginfo
if we change si_signo, not the tracee. task_pid_vnr() is not namespace
friendly, but I think we don't care. At least now.
And the question:
ptrace_report_signal:
