summaryrefslogtreecommitdiff
path: root/arch
diff options
context:
space:
mode:
authorJason Wessel <jason.wessel@windriver.com>2009-12-11 17:43:18 +0300
committerJason Wessel <jason.wessel@windriver.com>2009-12-11 17:43:18 +0300
commit8097551d9ab9b9e3630694ad1bc6e12c597c515e (patch)
tree6d1f172a792f0acb0b3313e743f2b8bad791b270 /arch
parent028e7b175970be8fca58bfd7d61cc375babe40b7 (diff)
downloadlinux-8097551d9ab9b9e3630694ad1bc6e12c597c515e.tar.xz
kgdb,x86: do not set kgdb_single_step on x86
On an SMP system the kgdb_single_step flag has the possibility to indefinitely hang the system in the case. Consider the case where, CPU 1 has the schedule lock and CPU 0 is set to single step, there is no way for CPU 0 to run another task. The easy way to observe the problem is to make 2 cpus busy, and run the kgdb test suite. You will see that it hangs the system very quickly. while [ 1 ] ; do find /proc > /dev/null 2>&1 ; done & while [ 1 ] ; do find /proc > /dev/null 2>&1 ; done & echo V1 > /sys/module/kgdbts/parameters/kgdbts The side effect of this patch is that there is the possibility to miss a breakpoint in the case that a single step operation was executed to step over a breakpoint in common code. The trade off of the missed breakpoint is preferred to hanging the kernel. This can be fixed in the future by using kprobes or another strategy to step over planted breakpoints with out of line execution. CC: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Diffstat (limited to 'arch')
-rw-r--r--arch/x86/kernel/kgdb.c1
1 files changed, 0 insertions, 1 deletions
diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index aefae46aa646..dd74fe7273b1 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -400,7 +400,6 @@ int kgdb_arch_handle_exception(int e_vector, int signo, int err_code,
/* set the trace bit if we're stepping */
if (remcomInBuffer[0] == 's') {
linux_regs->flags |= X86_EFLAGS_TF;
- kgdb_single_step = 1;
atomic_set(&kgdb_cpu_doing_single_step,
raw_smp_processor_id());
}