From: Jason Wessel <jason.wessel@windriver.com>
To: Denis Joseph Barrow <D.Barow@option.com>
Cc: KGDB Mailing List <kgdb-bugreport@lists.sourceforge.net>,
linux-kernel@vger.kernel.org, gareth@valinux.com,
markus.t.metzger@intel.com
Subject: Re: getting false SIGTRAP breakpoints in kernel i.e. kernel hung unless gdb remotely attached on x86 & cont is issued
Date: Fri, 19 Sep 2008 14:38:49 -0500 [thread overview]
Message-ID: <48D3FFC9.5080701@windriver.com> (raw)
In-Reply-To: <48D3AAB0.3010504@option.com>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
Denis Joseph Barrow wrote:
>
> The patch gets my full blessing even if my blessing is unimportant.
>
Full regression testing has turned up another problem. If you single
step a system call with kgdb which is the same system call that ptrace
is stepping kgdb silently fails.
The complete fix to both problems is implemented in this patch, and it
has been regression tested across all the architectures.
This patch will be queued to the 2.6.27 fixes.
Jason.
[-- Attachment #2: user_space_single_step_check_v2.patch --]
[-- Type: text/x-diff, Size: 4455 bytes --]
From: Jason Wessel <jason.wessel@windriver.com>
Subject: [PATCH] kgdb, x86, arm, mips, powerpc: ignore user space single stepping
On the x86 arch, user space single step exceptions should be ignored
if they occur in the kernel space, such as ptrace stepping through a
system call.
First check if it is kgdb that is executing a single step, then ensure
it is not an accidental traversal into the user space, while in kgdb,
any other time the TIF_SINGLESTEP is set, kgdb should ignore the
exception.
On x86, arm, mips and powerpc, the kgdb_contthread usage was
inconsistent with the way single stepping is implemented in the kgdb
core. The arch specific stub should always set the
kgdb_cpu_doing_single_step correctly if it is single stepping. This
allows kgdb to correctly process an instruction steps if ptrace
happens to be requesting an instruction step over a system call.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
arch/arm/kernel/kgdb.c | 2 --
arch/mips/kernel/kgdb.c | 3 +--
arch/powerpc/kernel/kgdb.c | 5 ++---
arch/x86/kernel/kgdb.c | 18 +++++++++++-------
kernel/kgdb.c | 8 ++++----
5 files changed, 18 insertions(+), 18 deletions(-)
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -378,10 +378,8 @@ int kgdb_arch_handle_exception(int e_vec
if (remcomInBuffer[0] == 's') {
linux_regs->flags |= X86_EFLAGS_TF;
kgdb_single_step = 1;
- if (kgdb_contthread) {
- atomic_set(&kgdb_cpu_doing_single_step,
- raw_smp_processor_id());
- }
+ atomic_set(&kgdb_cpu_doing_single_step,
+ raw_smp_processor_id());
}
get_debugreg(dr6, 6);
@@ -466,9 +464,15 @@ static int __kgdb_notify(struct die_args
case DIE_DEBUG:
if (atomic_read(&kgdb_cpu_doing_single_step) ==
- raw_smp_processor_id() &&
- user_mode(regs))
- return single_step_cont(regs, args);
+ raw_smp_processor_id()) {
+ if (user_mode(regs))
+ return single_step_cont(regs, args);
+ break;
+ } else if (test_thread_flag(TIF_SINGLESTEP))
+ /* This means a user thread is single stepping
+ * a system call which should be ignored
+ */
+ return NOTIFY_DONE;
/* fall through */
default:
if (user_mode(regs))
--- a/kernel/kgdb.c
+++ b/kernel/kgdb.c
@@ -1462,7 +1462,7 @@ acquirelock:
* Get the passive CPU lock which will hold all the non-primary
* CPU in a spin state while the debugger is active
*/
- if (!kgdb_single_step || !kgdb_contthread) {
+ if (!kgdb_single_step) {
for (i = 0; i < NR_CPUS; i++)
atomic_set(&passive_cpu_wait[i], 1);
}
@@ -1475,7 +1475,7 @@ acquirelock:
#ifdef CONFIG_SMP
/* Signal the other CPUs to enter kgdb_wait() */
- if ((!kgdb_single_step || !kgdb_contthread) && kgdb_do_roundup)
+ if ((!kgdb_single_step) && kgdb_do_roundup)
kgdb_roundup_cpus(flags);
#endif
@@ -1494,7 +1494,7 @@ acquirelock:
kgdb_post_primary_code(ks->linux_regs, ks->ex_vector, ks->err_code);
kgdb_deactivate_sw_breakpoints();
kgdb_single_step = 0;
- kgdb_contthread = NULL;
+ kgdb_contthread = current;
exception_level = 0;
/* Talk to debugger with gdbserial protocol */
@@ -1508,7 +1508,7 @@ acquirelock:
kgdb_info[ks->cpu].task = NULL;
atomic_set(&cpu_in_kgdb[ks->cpu], 0);
- if (!kgdb_single_step || !kgdb_contthread) {
+ if (!kgdb_single_step) {
for (i = NR_CPUS-1; i >= 0; i--)
atomic_set(&passive_cpu_wait[i], 0);
/*
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -111,8 +111,6 @@ int kgdb_arch_handle_exception(int excep
case 'D':
case 'k':
case 'c':
- kgdb_contthread = NULL;
-
/*
* Try to read optional parameter, pc unchanged if no parm.
* If this was a compiled breakpoint, we need to move
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -236,8 +236,7 @@ int kgdb_arch_handle_exception(int vecto
atomic_set(&kgdb_cpu_doing_single_step, -1);
if (remcom_in_buffer[0] == 's')
- if (kgdb_contthread)
- atomic_set(&kgdb_cpu_doing_single_step, cpu);
+ atomic_set(&kgdb_cpu_doing_single_step, cpu);
return 0;
}
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -347,9 +347,8 @@ int kgdb_arch_handle_exception(int vecto
linux_regs->msr |= MSR_SE;
#endif
kgdb_single_step = 1;
- if (kgdb_contthread)
- atomic_set(&kgdb_cpu_doing_single_step,
- raw_smp_processor_id());
+ atomic_set(&kgdb_cpu_doing_single_step,
+ raw_smp_processor_id());
}
return 0;
}
next prev parent reply other threads:[~2008-09-19 19:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-17 13:47 getting false SIGTRAP breakpoints in kernel i.e. kernel hung unless gdb remotely attached on x86 & cont is issued Denis Joseph Barrow
2008-09-17 13:55 ` Jason Wessel
2008-09-17 14:20 ` Denis Joseph Barrow
2008-09-18 14:53 ` Jason Wessel
2008-09-19 12:31 ` Denis Joseph Barrow
2008-09-19 12:57 ` Jason Wessel
2008-09-19 13:35 ` Denis Joseph Barrow
2008-09-19 19:38 ` Jason Wessel [this message]
[not found] ` <49708E50.8080103@option.com>
2009-01-16 15:58 ` [PATCH]l gdb serial debugging appears be broken since at least 2.6.28-rc6 by tty layer now hopefully fixed Denis Joseph Barrow
2008-09-17 15:40 ` getting false SIGTRAP breakpoints in kernel i.e. kernel hung unless gdb remotely attached on x86 & cont is issued Denis Joseph Barrow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48D3FFC9.5080701@windriver.com \
--to=jason.wessel@windriver.com \
--cc=D.Barow@option.com \
--cc=gareth@valinux.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=markus.t.metzger@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.