But... I tried to understand these check and failed. Why do we need them?
They look unneeded to me, but of course I know nothing about s390.
It's not specific to s390. Other arch's have equivalent logic. As
with all things ptrace, I strongly suspect that they just blindly
copied the logic from some old i386 code and never contemplated the
actual intent.
AFAIK this is just part of some old defensive programming or partial
mitigation of the general problem that we overload the user signal
queue as a queue of debugger-induced hardware traps. This is some
very incomplete mitigation--the general problem is a known issue we
want to address in the future--but it's the status quo, so better
not to tweak it now in case it might be closing an observable hole
today in some usage pattern that someone might actually experience.
The general problem has many corners and races and we still have
those with or without this check. But consider e.g. the scenario
where the debugger PTRACE_SINGLESTEP'd into a long-blocking syscall
(read on a dangling pipe, etc.), then the debugger suddenly exits
without doing a proper PTRACE_DETACH. That is an entirely non-racey
case where TIF_SINGLE_STEP was left set but -ptrace is clear, so
without the check you could get the spurious SIGTRAP killing the
tracee (the once-was-tracee-and-no-longer, that is).
Perhaps nowadays exit_ptrace() leads to ptrace_disable() -
user_disable_single_step() and so the TIF_* bit is clear before
resuming and getting here (or at least with utrace, it leads to
UTRACE_DETACH and eventually to user_disable_single_step()). But at
least before that (and it looks like with the 2.6.32 ptrace code
still), it makes a difference in this scenario. So it is still an
open can of worms I don't want us to dive into this week, but at
least this one worm-escape hole should stay as plugged as it has
been these last 10+ years. (For extra credit, write up that case in
ptrace-tests and make it a KFAIL.)
Thanks,
Roland
