All of lore.kernel.org
 help / color / mirror / Atom feed
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
Subject: Re: getting false SIGTRAP breakpoints in kernel i.e. kernel hung unless gdb remotely attached on x86 & cont is issued
Date: Thu, 18 Sep 2008 09:53:24 -0500	[thread overview]
Message-ID: <48D26B64.5080605@windriver.com> (raw)
In-Reply-To: <48D1122F.6080101@option.com>

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Denis Joseph Barrow wrote:
> Hi Jason,
> The problem I believe is very reproducable.

It can be reproduced quite easily as it is a generic problem that
appears to have existed for quite a long time.

> I'm doing nothing special with kgdb just using it to help me with 3g
> modem driver development & my driver wasn't loaded when the problem
> occured.  I have the following command in my /boot/grub/menu.lst
> kernel parameter to enable gdb.
>
> kgdboc=/dev/ttyS0,115200 maxcpus=1


This was the key detail that was missing.  Along with the program and
other gdb details provided the source of the problem was not too hard
to track down.

When you attach to the running program with ptrace (via gdb), it
interrupts the system call and executing the high level "step" will
result in gdb executing a number of instruction step operations to try
to get back to an instruction which corresponds to the next valid line
of high level source code.

It was the 3rd or 4th instruction step that jumped back into the
kernel space because gdb ultimately tries to single step a system call
in your example.  For the kernel, single stepping a system call is a
special operation in that the system call must appear to complete
atomically and the user space ends up on the next user space assembly
instruction after the system call.  Behind the scenes the kernel
executes the system call and tracks this condition.

It appears kgdb needs to account for this condition as well, by simply
ignoring it when it occurs.

Please try the attached patch, as it will hopefully address the
problem.

Jason.

[-- Attachment #2: user_space_single_step_check.patch --]
[-- Type: text/x-diff, Size: 1262 bytes --]

From: Jason Wessel <jason.wessel@windriver.com>
Subjct: [PATCH] kgdb,x86: 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.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>

---
 arch/x86/kernel/kgdb.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -466,9 +466,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))

  reply	other threads:[~2008-09-18 14:53 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 [this message]
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
     [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=48D26B64.5080605@windriver.com \
    --to=jason.wessel@windriver.com \
    --cc=D.Barow@option.com \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /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.