aboutsummaryrefslogtreecommitdiffstats
path: root/arch/m68k/kernel/head.S
diff options
context:
space:
mode:
authorRoland McGrath <roland@redhat.com>2007-09-05 03:05:56 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-09-10 18:57:47 -0700
commit7d94143291e4e625e2bc3b1ebdc7143ee7a9a2f1 (patch)
treec4f8a974a33dd6ac1feacf18f217ee326c8af5eb /arch/m68k/kernel/head.S
parent897ee77bfba12b83752027427a41009961458ee6 (diff)
downloadkernel_samsung_tuna-7d94143291e4e625e2bc3b1ebdc7143ee7a9a2f1.zip
kernel_samsung_tuna-7d94143291e4e625e2bc3b1ebdc7143ee7a9a2f1.tar.gz
kernel_samsung_tuna-7d94143291e4e625e2bc3b1ebdc7143ee7a9a2f1.tar.bz2
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>
Diffstat (limited to 'arch/m68k/kernel/head.S')
0 files changed, 0 insertions, 0 deletions