utrace-ptrace && detach with signal semantics

[Roland McGrath]

> Currently, if a tracer does ptrace(DETACH, tracee, SIGXXX)
> and then another/same tracer does ptrace(ATTACH, tracee)
> then SIGXXX will not be reported to the new tracer.

Correct.

> Why? Should utrace-ptrace be 100% compatible here?

I think it should, yes.  There is a rationale for it that makes sense to
me, and it is most certainly consistent, observable behavior on which
existing applications could very well depend subtly, so regardless of
"right" I think this one is well within 100% bug-compatibility territory.

The rationale I see is that the debugger observed the signal, decided it
wanted the tracee to experience the normal effects of the signal and be
done with it after that.  If it's a termination signal, the debugger really
expects that the tracee can do nothing but die.  (Given the tortured
historic logic of the ptrace code paths, this applies only to signal stops
and only when it either passes back the same signal number or at least
another one that is not blocked.)  Now replace "debugger" with "monitor" or
(dismal) "security-checking syscall tracing product", or just shudder while
trying not to imagine what all inane things ptrace might already be in use
for.  It could be important to someone out there e.g. that some other
process of the tracee's UID cannot race in there and rescue it from dying.

> I do not think there is a "real life" application that does
> ATTACH + DETACH and relies on fact it must not see this sig.

We can hope, but we cannot assume.  There are always better ways to achieve
the same true ends than the corner case examples like the one I gave, but
that doesn't mean people haven't written the stupid ones in applications
already shipped long ago and never to be rethought again (until we get the
blame for breaking them in the new kernel).


Thanks,
Roland