README-linux-ptrace: correct the description of suppressed signals

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This commit is contained in:
Denys Vlasenko 2012-02-09 19:57:52 +01:00
parent bdec9cbceb
commit 0ed9947c14

View File

@ -53,7 +53,7 @@ process (all its threads), even if some threads of the process are
ptraced. ptraced.
Tracer can kill a tracee with ptrace(PTRACE_KILL, pid, 0, 0). This Tracer can kill a tracee with ptrace(PTRACE_KILL, pid, 0, 0). This
opeartion is deprecated, use kill/tgkill(SIGKILL) instead. operation is deprecated, use kill/tgkill(SIGKILL) instead.
^^^ Oleg prefers to deprecate it instead of describing (and needing to ^^^ Oleg prefers to deprecate it instead of describing (and needing to
support) PTRACE_KILL's quirks. support) PTRACE_KILL's quirks.
@ -165,17 +165,13 @@ Note that sig value may be different from WSTOPSIG(status) value -
tracer can cause a different signal to be injected. tracer can cause a different signal to be injected.
Note that suppressed signal still causes syscalls to return Note that suppressed signal still causes syscalls to return
prematurely. Restartable syscalls will be restarted (tracer will prematurely. Kernel should always restart the syscall in this case:
observe tracee to execute restart_syscall(2) syscall if tracer uses tracer would observe a new syscall-enter-stop for the same syscall,
PTRACE_SYSCALL), non-restartable syscalls (for example, nanosleep) may or, in case of syscalls returning ERESTART_RESTARTBLOCK,
return with -EINTR even though no observable signal is injected to the tracer would observe a syscall-enter-stop for restart_syscall(2)
tracee. syscall. There may still be bugs in this area which cause some syscalls
to instead return with -EINTR even though no observable signal
Note that restarting ptrace commands issued in ptrace-stops other than was injected to the tracee.
signal-delivery-stop are not guaranteed to inject a signal, even if sig
is nonzero. No error is reported, nonzero sig may simply be ignored.
Ptrace users should not try to "create new signal" this way: use
tgkill(2) instead.
This is a cause of confusion among ptrace users. One typical scenario This is a cause of confusion among ptrace users. One typical scenario
is that tracer observes group-stop, mistakes it for is that tracer observes group-stop, mistakes it for