]> git.baikalelectronics.ru Git - kernel.git/commit
Fix spurious syscall tracing after PTRACE_DETACH + PTRACE_ATTACH
authorRoland McGrath <roland@redhat.com>
Wed, 5 Sep 2007 10:05:56 +0000 (03:05 -0700)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Tue, 11 Sep 2007 01:57:47 +0000 (18:57 -0700)
commitccf90b6df77095627698370d9851c88ed2e0ca2c
treec4f8a974a33dd6ac1feacf18f217ee326c8af5eb
parentb4a9ac0c709bcb735e352251b44112b5adb015a1
Fix spurious syscall tracing after PTRACE_DETACH + PTRACE_ATTACH

When PTRACE_SYSCALL was used and then PTRACE_DETACH is used, the
TIF_SYSCALL_TRACE flag is left set on the formerly-traced task.  This
means that when a new tracer comes along and does PTRACE_ATTACH, it's
possible he gets a syscall tracing stop even though he's never used
PTRACE_SYSCALL.  This happens if the task was in the middle of a system
call when the second PTRACE_ATTACH was done.  The symptom is an
unexpected SIGTRAP when the tracer thinks that only SIGSTOP should have
been provoked by his ptrace calls so far.

A few machines already fixed this in ptrace_disable (i386, ia64, m68k).
But all other machines do not, and still have this bug.  On x86_64, this
constitutes a regression in IA32 compatibility support.

Since all machines now use TIF_SYSCALL_TRACE for this, I put the
clearing of TIF_SYSCALL_TRACE in the generic ptrace_detach code rather
than adding it to every other machine's ptrace_disable.

Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
arch/i386/kernel/ptrace.c
arch/ia64/kernel/ptrace.c
arch/m68k/kernel/ptrace.c
kernel/ptrace.c