Re: [Kgdb-bugreport] Posted kdb doc, and a question about unused env variables

[Jason Wessel]

On 06/29/2011 07:30 PM, Tim Bird wrote:
 Hi all,

 I'm new to KDB, but I've been looking at the code and trying
 to document a few things.  I couldn't find any documentation on a few
 kdb features (initialization commands, defcmd, supported environment vars, 
 etc.)
 I wrote some up at:
 http://elinux.org/KDB

 If people could take a look and let me know if I got anything wrong,
 I would appreciate it

Sure.  I'll take a look.

 .

 Here's my question.  The following environment variables
 appear to be unimplemented or unused by KDB:

 BTARGS
 BTSYMARG


Hey thanks for pointing this out.   Previously before the unified kdb/kgdb was 
created, kdb used its own disassembler which supported decoding function 
arguments and printing the variable from registers and then the stack.

From the old kdb manual (pre-merge days)
---
  The BTARGS environment variable governs the maximum number of arguments
   that  are  printed for any single function.  On IA64 hardware, there is
   no difference between input  and  local  registers,  the  first  BTARGS
   registers  are  printed,  up  to  the  total  limit of input plus local
   registers.  Use a large value for BTARGS if you want to see  the  local
   registers on IA64.
---

Another clip from the old manual

---
   If  the  BTSYMARG  environment  variable is non-zero then any arguments
   that fall within the kernel or modules are converted to symbols.
---

So it was never intended that either of these variables get brought forward.

I'll include a patch to wipe them out in the next merge window.

Jason.

Note white space is mangled for now and fixed later in a real patch at merge 
window time

diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c
index 2f62fe8..7179eac 100644
--- a/kernel/debug/kdb/kdb_bt.c
+++ b/kernel/debug/kdb/kdb_bt.c
@@ -112,9 +112,8 @@ kdb_bt(int argc, const char **argv)
unsigned long addr;
long offset;
 
-   kdbgetintenv(BTARGS, argcount);  /* Arguments to print */
-   kdbgetintenv(BTAPROMPT, btaprompt);  /* Prompt after each
-* proc in bta */
+   /* Prompt after each proc in bta */
+   kdbgetintenv(BTAPROMPT, btaprompt);
 
if (strcmp(argv[0], bta) == 0) {
struct task_struct *g, *p;
diff --git a/kernel/debug/kdb/kdb_cmds b/kernel/debug/kdb/kdb_cmds
index 56c88e4..9834ad3 100644
--- a/kernel/debug/kdb/kdb_cmds
+++ b/kernel/debug/kdb/kdb_cmds
@@ -18,16 +18,12 @@ defcmd dumpcommon  Common kdb debugging
 endefcmd
 
 defcmd dumpall  First line debugging
-  set BTSYMARG 1
-  set BTARGS 9
   pid R
   -dumpcommon
   -bta
 endefcmd
 
 defcmd dumpcpu  Same as dumpall but only tasks on cpus
-  set BTSYMARG 1
-  set BTARGS 9
   pid R
   -dumpcommon
   -btc
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index be14779..b33116e 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -145,7 +145,6 @@ static char *__env[] = {
 #endif
  RADIX=16,
  MDCOUNT=8,  /* lines of md output */
- BTARGS=9,   /* 9 possible args in bt */
  KDB_PLATFORM_ENV,
  DTABCOUNT=30,
  NOSECT=1,
@@ -172,6 +171,7 @@ static char *__env[] = {
  (char *)0,
  (char *)0,
  (char *)0,
+ (char *)0,
 };


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH] sparc, kgdbts: fix compile regression with kgdb test suite

[Jason Wessel]

Commit 63ab25ebbc (kgdbts: unify/generalize gdb breakpoint adjustment)
introduced a compile regression on sparc.

kgdbts.c: In function 'check_and_rewind_pc':
kgdbts.c:307: error: implicit declaration of function 'instruction_pointer_set'

Simply add the correct macro definition for instruction pointer on the
Sparc architecture.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
Acked-by: Mike Frysinger vap...@gentoo.org
Acked-by: David S. Miller da...@davemloft.net
---
 arch/sparc/include/asm/ptrace.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/sparc/include/asm/ptrace.h b/arch/sparc/include/asm/ptrace.h
index c7ad3fe..b928b31 100644
--- a/arch/sparc/include/asm/ptrace.h
+++ b/arch/sparc/include/asm/ptrace.h
@@ -205,6 +205,7 @@ do {current_thread_info()-syscall_noerror = 1; \
 } while (0)
 #define user_mode(regs) (!((regs)-tstate  TSTATE_PRIV))
 #define instruction_pointer(regs) ((regs)-tpc)
+#define instruction_pointer_set(regs, val) ((regs)-tpc = (val))
 #define user_stack_pointer(regs) ((regs)-u_regs[UREG_FP])
 #define regs_return_value(regs) ((regs)-u_regs[UREG_I0])
 #ifdef CONFIG_SMP
-- 
1.7.1


--
5 Ways to Improve  Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [GIT PULL] kgdb compile fix for 3.0 rc7

[Jason Wessel]

Linus, please pull the for_linus branch to pick up a sparc compile
regression that was picked up early in the 3.0 cycle.

git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git 
for_linus

Thanks,
Jason.

---
The following changes since commit 3a5c3743f15f27237ab025736a981e2d0c9fdfed:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 (2011-07-18 
13:29:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git 
for_linus

Jason Wessel (1):
  sparc,kgdbts: fix compile regression with kgdb test suite

 arch/sparc/include/asm/ptrace.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)


--
5 Ways to Improve  Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 1/4] kdb: cleanup unused variables missed in the original kdb merge

[Jason Wessel]

The BTARGS and BTSYMARG variables do not have any function in the
mainline version of kdb.

Reported-by: Tim Bird tim.b...@am.sony.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/kdb/kdb_bt.c   |5 ++---
 kernel/debug/kdb/kdb_cmds   |4 
 kernel/debug/kdb/kdb_main.c |2 +-
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c
index 2f62fe8..7179eac 100644
--- a/kernel/debug/kdb/kdb_bt.c
+++ b/kernel/debug/kdb/kdb_bt.c
@@ -112,9 +112,8 @@ kdb_bt(int argc, const char **argv)
unsigned long addr;
long offset;
 
-   kdbgetintenv(BTARGS, argcount);  /* Arguments to print */
-   kdbgetintenv(BTAPROMPT, btaprompt);  /* Prompt after each
-* proc in bta */
+   /* Prompt after each proc in bta */
+   kdbgetintenv(BTAPROMPT, btaprompt);
 
if (strcmp(argv[0], bta) == 0) {
struct task_struct *g, *p;
diff --git a/kernel/debug/kdb/kdb_cmds b/kernel/debug/kdb/kdb_cmds
index 56c88e4..9834ad3 100644
--- a/kernel/debug/kdb/kdb_cmds
+++ b/kernel/debug/kdb/kdb_cmds
@@ -18,16 +18,12 @@ defcmd dumpcommon  Common kdb debugging
 endefcmd
 
 defcmd dumpall  First line debugging
-  set BTSYMARG 1
-  set BTARGS 9
   pid R
   -dumpcommon
   -bta
 endefcmd
 
 defcmd dumpcpu  Same as dumpall but only tasks on cpus
-  set BTSYMARG 1
-  set BTARGS 9
   pid R
   -dumpcommon
   -btc
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index be14779..b33116e 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -145,7 +145,6 @@ static char *__env[] = {
 #endif
  RADIX=16,
  MDCOUNT=8,  /* lines of md output */
- BTARGS=9,   /* 9 possible args in bt */
  KDB_PLATFORM_ENV,
  DTABCOUNT=30,
  NOSECT=1,
@@ -172,6 +171,7 @@ static char *__env[] = {
  (char *)0,
  (char *)0,
  (char *)0,
+ (char *)0,
 };
 
 static const int __nenv = (sizeof(__env) / sizeof(char *));
-- 
1.7.1


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [GIT PULL] kgdb/kdb updates for 3.1

[Jason Wessel]

Linus, please pull the for_linus branch to pick up the minor kgdb/kdb
cleanups accumulated in the last few months.

git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git 
for_linus

Thanks,
Jason.

---

The following changes since commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe:

  Linux 3.0 (2011-07-21 19:17:23 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git 
for_linus

Jason Wessel (4):
  kdb: cleanup unused variables missed in the original kdb merge
  kdb,kgdb: Implement switch and pass buffer from kdb - gdb
  kdb: Remove all references to DOING_KGDB2
  kdb,kgdb: Allow arbitrary kgdb magic knock sequences

 kernel/debug/gdbstub.c  |   22 +++---
 kernel/debug/kdb/kdb_bt.c   |5 ++---
 kernel/debug/kdb/kdb_cmds   |4 
 kernel/debug/kdb/kdb_debugger.c |   21 -
 kernel/debug/kdb/kdb_io.c   |   36 +---
 kernel/debug/kdb/kdb_main.c |4 ++--
 kernel/debug/kdb/kdb_private.h  |3 +--
 7 files changed, 53 insertions(+), 42 deletions(-)

--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 2/4] kdb, kgdb: Implement switch and pass buffer from kdb - gdb

[Jason Wessel]

When switching from kdb mode to kgdb mode packets were getting lost
depending on the size of the fifo queue of the serial chip.  When gdb
initially connects if it is in kdb mode it should entirely send any
character buffer over to the gdbstub when switching connections.

Previously kdb was zero'ing out the character buffer and this could
lead to gdb failing to connect at all, or a lengthy pause could occur
on the initial connect.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/gdbstub.c  |   22 +++---
 kernel/debug/kdb/kdb_debugger.c |   17 +++--
 kernel/debug/kdb/kdb_io.c   |   10 ++
 kernel/debug/kdb/kdb_private.h  |1 +
 4 files changed, 29 insertions(+), 21 deletions(-)

diff --git a/kernel/debug/gdbstub.c b/kernel/debug/gdbstub.c
index a11db95..3487248 100644
--- a/kernel/debug/gdbstub.c
+++ b/kernel/debug/gdbstub.c
@@ -42,6 +42,8 @@
 /* Our I/O buffers. */
 static charremcom_in_buffer[BUFMAX];
 static charremcom_out_buffer[BUFMAX];
+static int gdbstub_use_prev_in_buf;
+static int gdbstub_prev_in_buf_pos;
 
 /* Storage for the registers, in GDB format. */
 static unsigned long   gdb_regs[(NUMREGBYTES +
@@ -58,6 +60,13 @@ static int gdbstub_read_wait(void)
int ret = -1;
int i;
 
+   if (unlikely(gdbstub_use_prev_in_buf)) {
+   if (gdbstub_prev_in_buf_pos  gdbstub_use_prev_in_buf)
+   return remcom_in_buffer[gdbstub_prev_in_buf_pos++];
+   else
+   gdbstub_use_prev_in_buf = 0;
+   }
+
/* poll any additional I/O interfaces that are defined */
while (ret  0)
for (i = 0; kdb_poll_funcs[i] != NULL; i++) {
@@ -109,7 +118,6 @@ static void get_packet(char *buffer)
buffer[count] = ch;
count = count + 1;
}
-   buffer[count] = 0;
 
if (ch == '#') {
xmitcsum = hex_to_bin(gdbstub_read_wait())  4;
@@ -124,6 +132,7 @@ static void get_packet(char *buffer)
if (dbg_io_ops-flush)
dbg_io_ops-flush();
}
+   buffer[count] = 0;
} while (checksum != xmitcsum);
 }
 
@@ -1082,12 +1091,11 @@ int gdbstub_state(struct kgdb_state *ks, char *cmd)
case 'c':
strcpy(remcom_in_buffer, cmd);
return 0;
-   case '?':
-   gdb_cmd_status(ks);
-   break;
-   case '\0':
-   strcpy(remcom_out_buffer, );
-   break;
+   case '$':
+   strcpy(remcom_in_buffer, cmd);
+   gdbstub_use_prev_in_buf = strlen(remcom_in_buffer);
+   gdbstub_prev_in_buf_pos = 0;
+   return 0;
}
dbg_io_ops-write_char('+');
put_packet(remcom_out_buffer);
diff --git a/kernel/debug/kdb/kdb_debugger.c b/kernel/debug/kdb/kdb_debugger.c
index dd0b1b7..fe422d2 100644
--- a/kernel/debug/kdb/kdb_debugger.c
+++ b/kernel/debug/kdb/kdb_debugger.c
@@ -30,6 +30,8 @@ EXPORT_SYMBOL_GPL(kdb_poll_funcs);
 int kdb_poll_idx = 1;
 EXPORT_SYMBOL_GPL(kdb_poll_idx);
 
+static struct kgdb_state *kdb_ks;
+
 int kdb_stub(struct kgdb_state *ks)
 {
int error = 0;
@@ -39,6 +41,7 @@ int kdb_stub(struct kgdb_state *ks)
kdb_dbtrap_t db_result = KDB_DB_NOBPT;
int i;
 
+   kdb_ks = ks;
if (KDB_STATE(REENTRY)) {
reason = KDB_REASON_SWITCH;
KDB_STATE_CLEAR(REENTRY);
@@ -124,16 +127,6 @@ int kdb_stub(struct kgdb_state *ks)
kdbnearsym_cleanup();
if (error == KDB_CMD_KGDB) {
if (KDB_STATE(DOING_KGDB) || KDB_STATE(DOING_KGDB2)) {
-   /*
-* This inteface glue which allows kdb to transition in into
-* the gdb stub.  In order to do this the '?' or '' gdb serial
-* packet response is processed here.  And then control is
-* passed to the gdbstub.
-*/
-   if (KDB_STATE(DOING_KGDB))
-   gdbstub_state(ks, ?);
-   else
-   gdbstub_state(ks, );
KDB_STATE_CLEAR(DOING_KGDB);
KDB_STATE_CLEAR(DOING_KGDB2);
}
@@ -166,3 +159,7 @@ int kdb_stub(struct kgdb_state *ks)
return kgdb_info[ks-cpu].ret_state;
 }
 
+void kdb_gdb_state_pass(char *buf)
+{
+   gdbstub_state(kdb_ks, buf);
+}
diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 96fdaac..bd23326 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -35,8 +35,8 @@ static void kgdb_transition_check(char *buffer)
 {
int slen = strlen(buffer);
if (strncmp(buffer, $?#3f, slen) != 0 
-   strncmp(buffer, $qSupported#37, slen) != 0 
-   strncmp(buffer

[Kgdb-bugreport] [PATCH 4/4] kdb, kgdb: Allow arbitrary kgdb magic knock sequences

[Jason Wessel]

The first packet that gdb sends when the kernel is in kdb mode seems
to change with every release of gdb.  Instead of continuing to add
many different gdb packets, change kdb to automatically look for any
thing that looks like a gdb packet.

Example 1 cold start test:
echo g  /proc/sysrq-trigger
$D#44+

Example 2 cold start test:
echo g  /proc/sysrq-trigger
$3#33

The second one should re-enter kdb's shell right away and is purely a
test.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/kdb/kdb_io.c |   28 
 1 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 0dbcdfb..4802eb5 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -31,15 +31,21 @@ char kdb_prompt_str[CMD_BUFLEN];
 
 int kdb_trap_printk;
 
-static void kgdb_transition_check(char *buffer)
+static int kgdb_transition_check(char *buffer)
 {
-   int slen = strlen(buffer);
-   if (strncmp(buffer, $?#3f, slen) != 0 
-   strncmp(buffer, $qSupported, slen) != 0 
-   strncmp(buffer, +$qSupported, slen) != 0) {
+   if (buffer[0] != '+'  buffer[0] != '$') {
KDB_STATE_SET(KGDB_TRANS);
kdb_printf(%s, buffer);
+   } else {
+   int slen = strlen(buffer);
+   if (slen  3  buffer[slen - 3] == '#') {
+   kdb_gdb_state_pass(buffer);
+   strcpy(buffer, kgdb);
+   KDB_STATE_SET(DOING_KGDB);
+   return 1;
+   }
}
+   return 0;
 }
 
 static int kdb_read_get_key(char *buffer, size_t bufsize)
@@ -251,6 +257,10 @@ poll_again:
case 13: /* enter */
*lastchar++ = '\n';
*lastchar++ = '\0';
+   if (!KDB_STATE(KGDB_TRANS)) {
+   KDB_STATE_SET(KGDB_TRANS);
+   kdb_printf(%s, buffer);
+   }
kdb_printf(\n);
return buffer;
case 4: /* Del */
@@ -382,10 +392,12 @@ poll_again:
 * printed characters if we think that
 * kgdb is connecting, until the check
 * fails */
-   if (!KDB_STATE(KGDB_TRANS))
-   kgdb_transition_check(buffer);
-   else
+   if (!KDB_STATE(KGDB_TRANS)) {
+   if (kgdb_transition_check(buffer))
+   return buffer;
+   } else {
kdb_printf(%c, key);
+   }
}
/* Special escape to kgdb */
if (lastchar - buffer = 5 
-- 
1.7.1


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 3/4] kdb: Remove all references to DOING_KGDB2

[Jason Wessel]

The DOING_KGDB2 was originally a state variable for one of the two
ways to automatically transition from kdb to kgdb.  Purge all these
variables and just use one single state for the transition.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/kdb/kdb_debugger.c |4 +---
 kernel/debug/kdb/kdb_io.c   |2 +-
 kernel/debug/kdb/kdb_main.c |2 +-
 kernel/debug/kdb/kdb_private.h  |2 --
 4 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/kernel/debug/kdb/kdb_debugger.c b/kernel/debug/kdb/kdb_debugger.c
index fe422d2..d9ca9aa 100644
--- a/kernel/debug/kdb/kdb_debugger.c
+++ b/kernel/debug/kdb/kdb_debugger.c
@@ -126,10 +126,8 @@ int kdb_stub(struct kgdb_state *ks)
KDB_STATE_CLEAR(PAGER);
kdbnearsym_cleanup();
if (error == KDB_CMD_KGDB) {
-   if (KDB_STATE(DOING_KGDB) || KDB_STATE(DOING_KGDB2)) {
+   if (KDB_STATE(DOING_KGDB))
KDB_STATE_CLEAR(DOING_KGDB);
-   KDB_STATE_CLEAR(DOING_KGDB2);
-   }
return DBG_PASS_EVENT;
}
kdb_bp_install(ks-linux_regs);
diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index bd23326..0dbcdfb 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -399,7 +399,7 @@ poll_again:
strcmp(lastchar - 11, $qSupported) == 0) {
kdb_gdb_state_pass(lastchar - 11);
strcpy(buffer, kgdb);
-   KDB_STATE_SET(DOING_KGDB2);
+   KDB_STATE_SET(DOING_KGDB);
return buffer;
}
}
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index b33116e..63786e7 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -1386,7 +1386,7 @@ int kdb_main_loop(kdb_reason_t reason, kdb_reason_t 
reason2, int error,
}
 
if (result == KDB_CMD_KGDB) {
-   if (!(KDB_STATE(DOING_KGDB) || KDB_STATE(DOING_KGDB2)))
+   if (!KDB_STATE(DOING_KGDB))
kdb_printf(Entering please attach debugger 
   or use $D#44+ or $3#33\n);
break;
diff --git a/kernel/debug/kdb/kdb_private.h b/kernel/debug/kdb/kdb_private.h
index 03d332e..e381d10 100644
--- a/kernel/debug/kdb/kdb_private.h
+++ b/kernel/debug/kdb/kdb_private.h
@@ -21,7 +21,6 @@
 #define KDB_CMD_SS (-1003)
 #define KDB_CMD_SSB(-1004)
 #define KDB_CMD_KGDB (-1005)
-#define KDB_CMD_KGDB2 (-1006)
 
 /* Internal debug flags */
 #define KDB_DEBUG_FLAG_BP  0x0002  /* Breakpoint subsystem debug */
@@ -146,7 +145,6 @@ extern int kdb_state;
 * keyboard on this cpu */
 #define KDB_STATE_KEXEC0x0004  /* kexec issued */
 #define KDB_STATE_DOING_KGDB   0x0008  /* kgdb enter now issued */
-#define KDB_STATE_DOING_KGDB2  0x0010  /* kgdb enter now issued */
 #define KDB_STATE_KGDB_TRANS   0x0020  /* Transition to kgdb */
 #define KDB_STATE_ARCH 0xff00  /* Reserved for arch
 * specific use */
-- 
1.7.1


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] Question on monitor command over serial connection

[Jason Wessel]

On 08/02/2011 03:05 PM, Francois wrote:
 Hi,

 I'm using a 3.0 Kernel on x86 platform. I'm debugging over a (virtual)
 serial port. Here is the way I'm usually doing it
 - gdb is running on the host, and I attach to the Linux kernel running
 on the guest with target remote /dev/pts/..
 - on the guest I'm running echo ttyS0,115200 
 /sys/module/kgdboc/parameters/kgdboc
 - I hit Alt+SysRq+G on the guest console to break.

 This is very effective so far, and I was wondering if I could get the
 result of Alt+SysRq+T like commands within gdb.
 It thought this might be possible throught the use of the monitor command.

 Here is what I observed:
 - configuring the kernel with
 CONFIG_KGDB=y
 CONFIG_KGDB_SERIAL_CONSOLE=y
 # CONFIG_KGDB_KDB is not set
   I am able to make gdb break with a Alt+SysRq+G, but the monitor
 command is not available
 - configuring with the above and
 CONFIG_KGDB_KDB=y
   I am not able to make kgdb break using Alt+SysRq+G. Instead kdb is
 triggered on the console.

 Do you know if there is a way to have the monitor command working
 using kgdb over a serial connection ?


It is probably the case that the latest versions of gdb have the problem where 
they will not automatically cause the kdb shell to enter kgdb mode.   I just 
merged a patch to fix this in the v3.1 merge window.

What you can do to work around this is:

Alt+SysRq+g and then type kgdb and press enter at the kdb prompt.

From that point on the debug core will run in gdbstub mode, and you should be 
able to issue monitor commands, starting with monitor help, or of course 
what ever you like.

Jason.

--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] patch for kgdb.tmpl (for make pdfdocs)

[Jason Wessel]

On 12/13/2011 10:30 AM, Rajaneesh Acharya wrote:
 From 66937ca9088ebce297d78719a1487d7b07fdd6e9 Mon Sep 17 00:00:00 2001
 From: Rajaneesh Acharya rajaneesh.acha...@yahoo.com
 Date: Tue, 13 Dec 2011 10:46:08 -0500
 Subject: [PATCH] The following are the enhancements that removed the errors 
 while issuing make pdfdocs



This seems like a very worthwhile change, but it should be two separate commits.

The first one should move the file, and the second one should make the changes. 
Perhaps that is what you have provided here in the mail, but It did not appear 
as if the kgdb.tmpl was removed in your patch.

I am puzzled as to why we would need to copies of the same doc with different 
file extensions?

Jason.



--
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and 
improve service delivery. Take 5 minutes to use this Systems Optimization 
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] Anyone used KDB single-stepping on ARM

[Jason Wessel]

On 10/12/2011 12:41 PM, Tim Bird wrote:
 I've tried to use single-stepping ('ss' command) on ARM
 from KDB, without success.

 Has anyone done this - is it currently supported on ARM?

It is only supported via patches that are not in the mainline kernel the same 
is also true of the MIPS architecture.

The last consideration I had taken a look at was to consider using the kprobes 
for single stepping, assuming kprobes work ok on ARM, vs using emulation of 
single stepping with breakpoints.

The other possibility for newer arm hardward (v7 and up) is to use the 
hw_breakpoint API and plumb it into kdb/kgdb via the arch/arm/kernel/kgdb.c.  
It is probably time to take another look at this now since it was merged to the 
mainline in the last year.

Jason.

--
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and 
improve service delivery. Take 5 minutes to use this Systems Optimization 
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] KDB: Fix usability issues relating to the 'enter' key.

[Jason Wessel]

On 02/17/2012 05:52 PM, Andrei Warkentin wrote:
 This fixes the following problems:
 1) Typematic-repeat of 'enter' gives warning message.
 2) Use of 'keypad enter' gives warning message.
 3) Lag on the order of seconds between break and make when
expecting the enter break code. Seen under virtualized
environments such as VMware ESX.
 
 Explanations:
 1) Holding down 'enter' will not set a repeating sequence
of 0x1c(make)-0x9c(make), but a repeating sequence
of make codes, followed by one break code when the key
is released. Thus, it's wrong to expect the break code
after seeing the 'enter' make code.
 2) Keypad enter generates different make/break, namely
0xe0 0x1c and 0xe0 0x9c. The 'generic' logic handles
the 0xe0 escape already, but the special 'enter' logic
always expects '0x9c' and not '0xe0 0x9c', so you get
a warning message, again.
 3) When expecting the 'enter' break code, the code polls
the status register in a tight loop, like so -
  while ((inb(KBD_STATUS_REG)  KBD_STAT_OBF) == 0);
 
However, it really should do something like -
  while ((inb(KBD_STATUS_REG)  KBD_STAT_OBF) == 0)
 cpu_relax(); /* pause */
 
Basically, it's a common optimization to have a fast
path for accessing often accessed and slow changing I/O
in a virtualized environment. The tight spinning in KDB
seems to run against the logic by ESX keyboard virtualization
code to detect when the fast path or the slow path should
be used to satisfy the keyboard status read, leading to
multi-second timeouts before the 'real' status comes through.
Without knowing ESX internals, it's hard to say if this is
an ESX bug or not, but letting the VM be explicitely descheduled
seems to resolve the problem. I've seen something similar with
shared MMIO buffers with VMs on Hyper-V.
 
Anyway, given (3), (2) and (1), we might as well blow away the
entire special casing for 'enter'. The break codes will already
be handled correctly, and we get rid of the bugs with repeat
enters and keypad enter key. And of course, there is no
need to AND with 0x7f when checking for 'enter', because we'll
never ever get to this code with a break code (checked for much
earlier).
 
I tried to figure out the history behind the 'enter' key special
casing code, and it seems to have come from whatever the original
KDB patch was. Perhaps someone can chime in.
 


I did not write the original code, but I can explain why there was some special 
logic.

When you restore the system back to the running state you do not want to send 
any other key scan codes back to the kernel.  The idea being that you type go 
and press enter to resume kernel execution.  At that point you do not want to 
send a random scan code back to the kernel, ideally you want to leave 
everything as it was.  This also handled the case where there was a PS/2 style 
mouse attached.

I do have a question about part of the section you deleted.


 Tested on ESX 5.0 and QEMU.
 
 Signed-off-by: Andrei Warkentin andr...@vmware.com
 ---
  kernel/debug/kdb/kdb_keyboard.c |   28 +---
  1 files changed, 1 insertions(+), 27 deletions(-)
 
 diff --git a/kernel/debug/kdb/kdb_keyboard.c b/kernel/debug/kdb/kdb_keyboard.c
 index 4bca634..ed4a2f9 100644
 --- a/kernel/debug/kdb/kdb_keyboard.c
 +++ b/kernel/debug/kdb/kdb_keyboard.c
 @@ -178,34 +178,8 @@ int kdb_get_kbd_char(void)
   return -1;  /* ignore unprintables */
   }
  
 - if ((scancode  0x7f) == 0x1c) {
 - /*
 -  * enter key.  All done.  Absorb the release scancode.
 -  */
 - while ((inb(KBD_STATUS_REG)  KBD_STAT_OBF) == 0)
 - ;

Seems there is a bug here.  There is a cpu_relax() missing.

 -
 - /*
 -  * Fetch the scancode
 -  */
 - scancode = inb(KBD_DATA_REG);
 - scanstatus = inb(KBD_STATUS_REG);
 -
 - while (scanstatus  KBD_STAT_MOUSE_OBF) {

There should also be a cpu_relax() right here.

 - scancode = inb(KBD_DATA_REG);
 - scanstatus = inb(KBD_STATUS_REG);
 - }
 -


If you put the two cpu_relax() pieces in do you still end up with a problem?  
If this does not work for you the possibility to exists to clear the 
keyboard/mouse state on the kdb exit.

Thanks,
Jason.

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] KDB: Fix usability issues relating to the 'enter' key.

[Jason Wessel]

On 02/26/2012 07:10 AM, Jason Wessel wrote:
 On 02/17/2012 05:52 PM, Andrei Warkentin wrote:
 This fixes the following problems:
 1) Typematic-repeat of 'enter' gives warning message.
 2) Use of 'keypad enter' gives warning message.
 3) Lag on the order of seconds between break and make when
expecting the enter break code. Seen under virtualized
environments such as VMware ESX.

 Explanations:
 1) Holding down 'enter' will not set a repeating sequence
of 0x1c(make)-0x9c(make), but a repeating sequence
of make codes, followed by one break code when the key
is released. Thus, it's wrong to expect the break code
after seeing the 'enter' make code.
 2) Keypad enter generates different make/break, namely
0xe0 0x1c and 0xe0 0x9c. The 'generic' logic handles
the 0xe0 escape already, but the special 'enter' logic
always expects '0x9c' and not '0xe0 0x9c', so you get
a warning message, again.
 3) When expecting the 'enter' break code, the code polls
the status register in a tight loop, like so -
  while ((inb(KBD_STATUS_REG)  KBD_STAT_OBF) == 0);

However, it really should do something like -
  while ((inb(KBD_STATUS_REG)  KBD_STAT_OBF) == 0)
 cpu_relax(); /* pause */

Basically, it's a common optimization to have a fast
path for accessing often accessed and slow changing I/O
in a virtualized environment. The tight spinning in KDB
seems to run against the logic by ESX keyboard virtualization
code to detect when the fast path or the slow path should
be used to satisfy the keyboard status read, leading to
multi-second timeouts before the 'real' status comes through.
Without knowing ESX internals, it's hard to say if this is
an ESX bug or not, but letting the VM be explicitely descheduled
seems to resolve the problem. I've seen something similar with
shared MMIO buffers with VMs on Hyper-V.

Anyway, given (3), (2) and (1), we might as well blow away the
entire special casing for 'enter'. The break codes will already
be handled correctly, and we get rid of the bugs with repeat
enters and keypad enter key. And of course, there is no
need to AND with 0x7f when checking for 'enter', because we'll
never ever get to this code with a break code (checked for much
earlier).

I tried to figure out the history behind the 'enter' key special
casing code, and it seems to have come from whatever the original
KDB patch was. Perhaps someone can chime in.

 


Andrei, if you agree with the attached patch, I'll put it in the merge queue.  
If you find problems we can go another iteration. :-)

Cheers,
Jason.
--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] KDB: Fix usability issues relating to the 'enter' key.

[Jason Wessel]

On 02/26/2012 07:04 PM, Andrei Warkentin wrote:
 Hi,
 
 - Original Message -
 From: Jason Wessel jason.wes...@windriver.com
 To: Andrei Warkentin andr...@vmware.com
 Cc: kgdb-bugreport@lists.sourceforge.net, linux-ker...@vger.kernel.org
 Sent: Sunday, February 26, 2012 8:58:37 AM
 Subject: Re: [PATCH] KDB: Fix usability issues relating to the 'enter' key.
 

 Andrei, if you agree with the attached patch, I'll put it in the
 merge queue.  If you find problems we can go another iteration. :-)

 
 Nak. As I've mentioned in my original email, I went down this route as well, 
 only
 to ask the question of why the special ENTER code was there, since all it did
 was introduce problems elsewhere (like repeat ENTER handling, KP ENTER 
 key...).
 This is exactly why my solution was to get rid of the special ENTER code 
 altogether.
 
 The code in kgdboc already will do input device reset on kdb exit, so there 
 is no need
 to explicitely empty out the keyboard FIFO on every ENTER.
 

Did you try the patch I sent?  It might not address the key repeat
problem, but this is some thing I had not yet duplicated.  Outside of
the warning message (which was killed off in the patch), was there
garbage characters or some notable behavior?  Was it something you
could see in qemu or only in ESX?

Having authored the keyboard/input handler with some suggestions from
Dmitry, I was fairly certain it had no way to prevent the leak of the
up keystroke unless you have the KDB specific capture where it waits
to act on the key up event for an enter keystroke.  The cleanup
handler only cleans up state events where keys were down at the time
the debug core became active.  It will not prevent the leak of key
strokes or state changes while the kernel was stopped.  The goofy
enter handler was supposed to take care of that.

I conclusively proved there is event leakage from using the original
patch you provided. Here is the test case, which you should be able to
execute with qemu or kvm (since you also mentioned that was what you
were previously using).

1) boot the qemu
2) Use kgdboc=kbd
3) break into the debugger to the kdb prompt
4) type g but to not press return
5) Connect to the qemu back end debug connection with gdb and set a
   breakpoint at line 402 of atkbd.c which should be the call to:
input_event(dev, EV_MSC, MSC_RAW, code);
6) continue the gdb connection
7) In the qemu monitor enter the command:
sendkey ret 4000

After 4 seconds when the key is released you will catch the leaked
event in the atkbd.c, and if you had X running it propagates all the
way up the input chain.

Jason.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCHv3 1/3] NETPOLL: Extend rx_hook support.

[Jason Wessel]

On 02/26/2012 09:30 PM, Andrei Warkentin wrote:
 From: Andrei Warkentin andr...@vmware.com
 
 Pass down source information to rx_hook, useful
 for accepting connections from unspecified clients.
 
 Cc: kgdb-bugreport@lists.sourceforge.net
 Cc: Jason Wessel jason.wes...@windriver.com
 Cc: Matt Mackall m...@selenic.com
 Signed-off-by: Andrei Warkentin andrey.warken...@gmail.com
 Signed-off-by: Andrei Warkentin andr...@vmware.com
 ---
  include/linux/netpoll.h |   10 +-
  net/core/netpoll.c  |   10 --
  2 files changed, 13 insertions(+), 7 deletions(-)
 
 diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
 index 5dfa091..9a9cfa1 100644
 --- a/include/linux/netpoll.h
 +++ b/include/linux/netpoll.h
 @@ -11,12 +11,19 @@
  #include linux/interrupt.h
  #include linux/rcupdate.h
  #include linux/list.h
 +#include linux/if_ether.h
 +#include net/tcp.h
 +#include net/udp.h
  
  struct netpoll {
   struct net_device *dev;
   char dev_name[IFNAMSIZ];
   const char *name;
 - void (*rx_hook)(struct netpoll *, int, char *, int);
 + void (*rx_hook)(struct netpoll *,
 + u8 *h_source,
 + __be32 saddr,
 + struct udphdr *,
 + char *, int);


I am just now starting to look how this patch set compares to kgdboe.  For the 
kgdboe the patch is a bit different.  The kgdboe opted to just pass the skb so 
as to cut down on the number of arguments to the function call.

From the kgdboe patch:

-   void (*rx_hook)(struct netpoll *, int, char *, int);
+   void (*rx_hook)(struct netpoll *, int, char *, int, struct sk_buff *);


  
   __be32 local_ip, remote_ip;
   u16 local_port, remote_port;
 @@ -40,6 +47,7 @@ struct netpoll_info {
   struct netpoll *netpoll;
  };
  
 +void netpoll_poll_dev(struct net_device *dev);
  void netpoll_send_udp(struct netpoll *np, const char *msg, int len);
  void netpoll_print_options(struct netpoll *np);
  int netpoll_parse_options(struct netpoll *np, char *opt);
 diff --git a/net/core/netpoll.c b/net/core/netpoll.c
 index 3d84fb9..c182bb2 100644
 --- a/net/core/netpoll.c
 +++ b/net/core/netpoll.c
 @@ -26,8 +26,6 @@
  #include linux/workqueue.h
  #include linux/slab.h
  #include linux/export.h
 -#include net/tcp.h
 -#include net/udp.h
  #include asm/unaligned.h
  #include trace/events/napi.h
  
 @@ -189,7 +187,7 @@ static void service_arp_queue(struct netpoll_info *npi)
   }
  }
  
 -static void netpoll_poll_dev(struct net_device *dev)
 +void netpoll_poll_dev(struct net_device *dev)


This is interesting and I will have to look into this further...  A large part 
of the reason kgdboe never went anywhere was all around the locking problems 
the ability to safely use the network hardware and restore the state when it 
was done.  It appears you made this change so as to make a lockless call 
directly instead of going through netpoll_poll().  I am not entirely sure you 
could safely do this.

In kgdboe we always had:

+static int eth_get_char(void)
+{
+   int chr;
+
+   while (atomic_read(in_count) == 0)
+   netpoll_poll(np);


If it is the case that you really can safely call the netpoll_poll_dev() 
without the locks then the horrible sync irq state etc... could go away in 
kgdboe, and then it would be worth considering digging up all the ethernet 
polling errata fixes that live of out the mainline and perhaps submit some for 
review.

Jason.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] KDB: Fix usability issues relating to the 'enter' key.

[Jason Wessel]

On 02/27/2012 05:18 PM, Andrei Warkentin wrote:
 Hi,

 - Original Message -
 From: Jason Wessel jason.wes...@windriver.com
 To: Andrei Warkentin awarken...@vmware.com
 Cc: kgdb-bugreport@lists.sourceforge.net, linux-ker...@vger.kernel.org, 
 Andrei Warkentin andr...@vmware.com
 Sent: Monday, February 27, 2012 5:50:59 PM
 Subject: Re: [PATCH] KDB: Fix usability issues relating to the 'enter' key.

 Did you try the patch I sent?  It might not address the key repeat
 problem, but this is some thing I had not yet duplicated.  Outside of
 the warning message (which was killed off in the patch), was there
 garbage characters or some notable behavior?  Was it something you
 could see in qemu or only in ESX?
 Let me elaborate. The cpu_relax() you added solves the hanging.

 Having authored the keyboard/input handler with some suggestions from
 Dmitry, I was fairly certain it had no way to prevent the leak of the
 up keystroke unless you have the KDB specific capture where it waits
 to act on the key up event for an enter keystroke.  The cleanup
 handler only cleans up state events where keys were down at the time
 the debug core became active.  It will not prevent the leak of key
 strokes or state changes while the kernel was stopped.  The goofy
 enter handler was supposed to take care of that.

 I conclusively proved there is event leakage from using the original
 patch you provided. Here is the test case, which you should be able
 to
 execute with qemu or kvm (since you also mentioned that was what you
 were previously using).

 1) boot the qemu
 2) Use kgdboc=kbd
 3) break into the debugger to the kdb prompt
 4) type g but to not press return
 5) Connect to the qemu back end debug connection with gdb and set a
breakpoint at line 402 of atkbd.c which should be the call to:
  input_event(dev, EV_MSC, MSC_RAW, code);
 6) continue the gdb connection
 7) In the qemu monitor enter the command:
 sendkey ret 4000

 After 4 seconds when the key is released you will catch the leaked
 event in the atkbd.c, and if you had X running it propagates all the
 way up the input chain.
 I know I should have read deeper into the input code. I assumed it performed 
 a reset
 on the input device. Assumptions are bad. Sorry.

 So here is the thing. With the patch you sent, you would still leak the break
 keypress for the keypad enter. This is because the break code for KP ENTER is 
 0xe0 0x9c,
 and the inb(KBD_DATA_REG) done in the goofy handler will read just the 0xe0 
 part, leaving
 0x9c behind, which will be leaked out.

 So here is my question - do you want me to fix the existing goofy handler to 
 properly
 handle KP ENTER and ENTER repeats? Or do you think it's appropriate to empty 
 out the
 FIFO during KDB exit as part of post_exp kgdb_io op? Or reset the input 
 device?

Thanks for the explanation.  I agree that we still have a leak with the patch I 
had sent you.  The old kdb code simply was incomplete and likely assumed people 
didn't ever use anything except the main keyboard's enter key.

I think the right choice is to correctly handle any that generates enter/return 
and do not leave the kdb keyboard handler until the release scan code is 
processed.  We have to do this because the physical release delay will always 
generate another scan code later on regardless of clearing the fifo or 
resetting the device.  The computer is simply faster than the human behind the 
console in this case. :-)

If you have some idea how to correctly fix up the KP ENTER please send a patch, 
else I will have a look at it sometime soon.  It is definitely worth fixing.

Cheers,
Jason.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] KDB: Fix usability issues relating to the 'enter' key.

[Jason Wessel]

I think we are a lot closer this time.  I attached a new patch based
on your prior version.

On 02/27/2012 10:26 PM, Andrei Warkentin wrote:
 This fixes the following problems:
 1) Typematic-repeat of 'enter' gives warning message
 and leaks make/break if KDB exits. Repeats
 look something like 0x1c 0x1c  0x9c
 2) Use of 'keypad enter' gives warning message and
 leaks the ENTER break/make code out if KDB exits.
 KP ENTER repeats look someting like 0xe0 0x1c
 0xe0 0x1c ... 0xe0 0x9c.
 3) Lag on the order of seconds between break and make when
 expecting the enter break code. Seen under virtualized
 environments such as VMware ESX.

 The existing special enter handler tries to glob the
 enter break code, but this fails if the other (KP) enter
 was used, or if there was a key repeat. It also fails
 if you mashed some keys along with enter, and you ended
 up with a non-enter make or non-enter break code coming
 after the enter make code. So first, we modify the handler
 to handle these cases. But performing these actions on
 every enter is annoying since now you can't hold ENTER down
 to scroll mored messages in KDB. Since this special
 behaviour is only necessary to handle the exiting KDB
 ('g' + ENTER) without leaking scancodes to the OS, we
 perform the cleanup in kgdboc_post_exp_handler path.

This is the wrong place to do this.  The cleanup needs to get executed
any time you are going to leave kdb_main(), because there are a few
conditions like cpu switch, and transition to kgdb where you would
leak the enter code on to the buffer handler without ever returning to
the OS.  Also if you did not set CONFIG_KDB_KEYBOARD your patch did
not compile properly.  We could have fixed this by moving the code to
the input cleanup in kgdboc, but this is not needed at all if you take
a look at the revised version.



 Fixed previous regression where if kbd was not used
 to 'g' + ENTER, the cleanup code would hang.


Was this a regression in the out of tree code or something in the
mainline kdb?

 index 4bca634..34a8722 100644
 --- a/kernel/debug/kdb/kdb_keyboard.c
 +++ b/kernel/debug/kdb/kdb_keyboard.c
 +void kdb_kbd_cleanup_state(void)
 +{
 + int scancode, scanstatus;
 +
 + /*
 + * Nothing to clean up, since either
 + * ENTER was never pressed, or has already
 + * gotten cleaned up.
 + */
 + if (!kbd_last_ret)
 + return;


I added kbd_last_ret = 0; right here so this cannot get triggered a
second time if the kdb main loop is entered and exited without going
to the shell (which can happen on a soft single step operation on some archs).


Jason.

PS We can iterate other patches you sent after we settle on this one.
Thanks!
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCHv3 1/3] NETPOLL: Extend rx_hook support.

[Jason Wessel]

On 02/27/2012 05:33 PM, Andrei Warkentin wrote:
 From: Jason Wessel jason.wes...@windriver.com
 To: Andrei Warkentin andrey.warken...@gmail.com
 Cc: net...@vger.kernel.org, linux-ker...@vger.kernel.org, Andrei Warkentin 
 andr...@vmware.com,
 kgdb-bugreport@lists.sourceforge.net, Matt Mackall m...@selenic.com
 Sent: Monday, February 27, 2012 6:17:12 PM
 Subject: Re: [PATCHv3 1/3] NETPOLL: Extend rx_hook support.


 I am just now starting to look how this patch set compares to kgdboe.
  For the kgdboe the patch is a bit different.  The kgdboe opted to
 just pass the skb so as to cut down on the number of arguments to
 the function call.

 From the kgdboe patch:

 -   void (*rx_hook)(struct netpoll *, int, char *, int);
 +   void (*rx_hook)(struct netpoll *, int, char *, int, struct
 sk_buff *);


 
 Interesting, I thought about passing the skb, but decided I didn't
 want to copy and paste the skb parsing code, especially given
 that it's always UDP anyway. I still have reservations about
 passing the physical address, but I don't think anyone tried
 to use netpoll or a non-ethernet device anyway.


With some input from the netdev folks we should decide what makes the most 
sense and stick with that implementation.  The previous kgdboe change to just 
pass the skb was signed off long ago as something ok.

 +while (atomic_read(in_count) == 0)
 +netpoll_poll(np);


 If it is the case that you really can safely call the
 netpoll_poll_dev() without the locks then the horrible sync irq
 state etc... could go away in kgdboe, and then it would be worth
 considering digging up all the ethernet polling errata fixes that
 live of out the mainline and perhaps submit some for review.



The code has changed since the last time that kgdboe actually worked.
The v3.1 commit 234b921dbcf killed off the netpoll_poll() function
as well as the exports needed to allow kgdboe to work as a kernel
module.  The patch you created here also needs to once again export
the netpoll_poll_dev() so that we can call it from a kernel module
because kgdboe or the ethernet kdb patch you submitted should be able
to be used a loadable module as well as a builtin.

 
 I didn't look deeply at kgdboe (probably should have...). Anyway, netpoll_poll
 doesn't seem to exist. netpoll_poll_dev is called from netpoll_send_skb_on_dev
 and the only contract I see is running with the interrupts disabled - 
 something
 that is satisfied by running in the context of KDB.


All that netpoll_poll() did was to call netpoll_poll_dev().  I have
not yet looked at the differences between kgdboe and the netkdb code
you proposed but I would have suspected it also falls victim to the
ethernet preemption problem which prevented kgdboe from ever being
considered for a mainline merge.  Certainly there are ways to fix this
problem but most involved changes to scheduling, core net code, or
substantial driver specific changes.

I almost have kgdboe working against the 3.3 kernel so we can have
both a code and functional comparison.  I would like to do some house
cleaning and merging of all the other out of tree patches for things
like kgdb over usb as well as kdb usb keyboard, so we can see if any
of it makes sense to submit to the mainline.


 
 This is slight OT, but...are WiFi drivers sufficiently similar that netpoll 
 just works?

Yes and no.  Yes, you could use the NET_POLL api to transmit packets
if the driver implemented polling hooks, but no in the sense that most
of the time you need a user space driver to manage the keys which are
time sensitive for things like WPA (usually the job of wpa
supplicant).  This is going to prevent you from having WiFi work at
all while the kernel is in the critical exception state.

Jason.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCHv3 1/3] NETPOLL: Extend rx_hook support.

[Jason Wessel]

On 03/01/2012 03:04 PM, Andrei Warkentin wrote:
 - Original Message -
 From: Andrei Warkentin awarken...@vmware.com
 To: Jason Wessel jason.wes...@windriver.com
 Cc: net...@vger.kernel.org, linux-ker...@vger.kernel.org, Andrei Warkentin 
 andr...@vmware.com,
 kgdb-bugreport@lists.sourceforge.net, Matt Mackall m...@selenic.com, 
 Andrei Warkentin
 andrey.warken...@gmail.com
 Sent: Tuesday, February 28, 2012 12:43:52 PM
 Subject: Re: [PATCHv3 1/3] NETPOLL: Extend rx_hook support.

 All that netpoll_poll() did was to call netpoll_poll_dev().  I have
 not yet looked at the differences between kgdboe and the netkdb
 code
 you proposed but I would have suspected it also falls victim to the
 ethernet preemption problem which prevented kgdboe from ever being
 considered for a mainline merge.  Certainly there are ways to fix
 this
 problem but most involved changes to scheduling, core net code, or
 substantial driver specific changes.

 I see, I read up on the issues w.r.t. preemption. Could this be
 worked
 around by modifiying affected drivers to bypass locking if they are
 used in KDB context? Make some accessor netdev-specific lock/unlocks
 that won't do anything if running in KDB context.


 By the way, is there a good way to repro the preemption case? Hopefully this 
 doesn't
 involve some crazy hardware...


I have several cases which will usually hang the machine fairly quickly, but 
they all involve using gdb and a target using SMP.  Most often it is as simple 
as this:

* Use an SMP system with with at least 2 cores
* Start two threads rapidly running some processes
 while [ 1 ] ; do date  /dev/null ; done 
 while [ 1 ] ; do date  /dev/null ; done 
* Connect with gdb to kgdb and set a breakpoint at do_fork
   Now do c
   Now do c 1000

Generally the system will hang long before you get 1000 breakpoints hit and it 
will be a condition where there is a lock needed to create an skb, or the 
ethernet driver is preempted or some part of the network stack is preempted (or 
holding a lock) on the non master cpu.

There is another condition that is hard to catch that involves a task migrating 
from one cpu to the next, but we'll stick to the simple test case I described 
above for now.

I did have a question, because it seems you were using qemu / kvm.   I have a 
number of test cases that use kvm, but the netkkgdb does not seem to work with 
the nc.  My question is how am I supposed to actually use the netkgdb?

Here is what I observe on the target system:

insmod netkgdb.ko netkgdb=@/,@10.0.2.2/
echo g  /proc/sysrq-trigger

On my host system:
nc.traditional -l -u -p 

I will type help, and then the netkgdb is toast.  It doesn't seem to respond 
anymore.

Jason.

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 3/4] kgdb: Respect that flush op is optional

[Jason Wessel]

On 03/16/2012 07:17 AM, Jan Kiszka wrote:
 Not all kgdb I/O drivers implement a flush operation. Adjust
 gdbstub_exit accordingly.

The flush is certainly optional.  The reason we never saw this bug is because 
it was only used by some code not in the mainline, where it is in fact patched. 
 The out of tree patch hooked into the reboot notifier.

It makes me wonder if using the reboot notifier is enough vs the call backs you 
placed in the critical power off points in your patch [4/4].   I'll respond 
separately to that thread because there are other folks in the CC line.

If we decide to roll with this series, I will definitely merge this patch, else 
I will remove the code since it is not used except for out of tree patches.

Thanks,
Jason.


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 4/4] kgdb: x86: Detach gdb if machine shuts down or reboots

[Jason Wessel]

On 03/16/2012 07:17 AM, Jan Kiszka wrote:
 Hook into machine restart/power-off/halt handlers and call gdbstub_exit
 so that a attached gdb frontend is properly informed. If kgdb is
 disabled or no frontend attached, gdbstub_exit will do nothing.
 


We have long had an out of tree patch which hooked the reboot notifier, vs 
adding call backs to the actual reboot functions.  It seems at first glance 
that all of cases that Jan probably cares about are actually caught by the 
reboot notifier.

I attached the patch I am referencing, and perhaps Jan can try it out.   It 
applies on top of Jan's series at the moment.

A few more comments first.

  static void __machine_emergency_restart(int emergency)
  {
   reboot_emergency = emergency;
 + gdbstub_exit(1);


If we do have to add callbacks at the arch level, my preference is to pass the 
stop code like you would have received in the reboot notifier.  Specifically 
something like:  gdbstub_exit(SYS_RESTART).

   machine_ops.emergency_restart();
  }
  
 @@ -730,6 +732,7 @@ struct machine_ops machine_ops = {
  
  void machine_power_off(void)
  {
 + gdbstub_exit(0);


Similarly gdbstub_exit(SYS_HALT) and so on.

Jan, what do you think about trying the reboot notifier version?

Thanks,
Jason.
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 1/4] kgdb: x86: Return all segment registers also in 64-bit mode

[Jason Wessel]

On 03/16/2012 07:17 AM, Jan Kiszka wrote:
 Even if the content is always 0, gdb expects us to return also ds,
 es, fs, and gs while in x86-64 mode. Do this to avoid ugly errors on
 info registers.

 Signed-off-by: Jan Kiszka jan.kis...@siemens.com
 ---
  arch/x86/include/asm/kgdb.h |6 +-
  arch/x86/kernel/kgdb.c  |6 --
  2 files changed, 9 insertions(+), 3 deletions(-)

 diff --git a/arch/x86/include/asm/kgdb.h b/arch/x86/include/asm/kgdb.h
 index 77e95f5..e857f1a 100644
 --- a/arch/x86/include/asm/kgdb.h
 +++ b/arch/x86/include/asm/kgdb.h
 @@ -64,9 +64,13 @@ enum regnames {
   GDB_PS, /* 17 */
   GDB_CS, /* 18 */
   GDB_SS, /* 19 */
 + GDB_DS, /* 20 */
 + GDB_ES, /* 21 */
 + GDB_FS, /* 22 */
 + GDB_GS, /* 23 */
  };
  #define GDB_ORIG_AX  57
 -#define DBG_MAX_REG_NUM  20
 +#define DBG_MAX_REG_NUM  24
  /* 17 64 bit regs and 3 32 bit regs */
  #define NUMREGBYTES  ((17 * 8) + (3 * 4))

You bumped the register numbers correctly, but you also need to add the correct 
padding to the NUMREGBYTES or you might not get a large enough memory block for 
the register struct.

You added 2 32 bit regs, so it should change to:

/* 17 64 bit regs and 5 32 bit regs */
#define NUMREGBYTES((17 * 8) + (5 * 4))


The rest should be fine.   I can test this and add it to the merge queue with 
the NUMREGBYTES change, unless you disagree.

Cheers,
Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 2/4] kgdb: Make gdbstub_exit a nop unless gdb is attached

[Jason Wessel]

On 03/16/2012 07:17 AM, Jan Kiszka wrote:
 This allows to call gdbstub_exit without worrying if
 - CONFIG_KGDB is enabled
 - if an kgdb I/O driver is loaded
 - if a gdb frontend is currently attached

If you took a look at the alternate patch I sent in the 4 of 4 response, I made 
a modification for kdb to continue to work properly, namely disconnect and do 
not emit characters if we are in kdb mode.


 diff --git a/kernel/debug/gdbstub.c b/kernel/debug/gdbstub.c
 index c22d8c2..5d7ed0a 100644
 --- a/kernel/debug/gdbstub.c
 +++ b/kernel/debug/gdbstub.c
 @@ -,6 +,9 @@ void gdbstub_exit(int status)
 unsigned char checksum, ch, buffer[3];
 int loop;

 + if (!dbg_io_ops || !kgdb_connected)
 + return;
 +
 buffer[0] = 'W';
 buffer[1] = hex_asc_hi(status);
 buffer[2] = hex_asc_lo(status);

I patched against what you originally had there.

--- a/kernel/debug/gdbstub.c
+++ b/kernel/debug/gdbstub.c
@@ -1110,8 +1110,11 @@ void gdbstub_exit(int status)
 {
unsigned char checksum, ch, buffer[3];
int loop;
+   if (!kgdb_connected)
+   return;
+   kgdb_connected = 0;
 
-   if (!dbg_io_ops || !kgdb_connected)
+   if (!dbg_io_ops || dbg_kdb_mode)
return;
 
buffer[0] = 'W';

---

Depending on what we come to agreement on with patches 2-4 in your series I'll 
fold the changes into the reboot notifier.

It is possible to have both the reboot notifier and the low level modifications 
to the arch specific reboot hooks as a final catch, but I am interested to see 
what you think about just using the reboot notifier.

Cheers,
Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 3/4] kgdb: Respect that flush op is optional

[Jason Wessel]

On 03/16/2012 07:53 AM, Jan Kiszka wrote:
 On 2012-03-16 13:46, Jason Wessel wrote:
 On 03/16/2012 07:17 AM, Jan Kiszka wrote:
 Not all kgdb I/O drivers implement a flush operation. Adjust
 gdbstub_exit accordingly.
 The flush is certainly optional.  The reason we never saw this bug is 
 because it was only used by some code not in the mainline, where it is in 
 fact patched.  The out of tree patch hooked into the reboot notifier.

 It makes me wonder if using the reboot notifier is enough vs the call backs 
 you placed in the critical power off points in your patch [4/4].   I'll 
 respond separately to that thread because there are other folks in the CC 
 line.
 I looked at other (granted: not kgdb-) archs and found them hooking
 their machine_xxx handlers. Also, do we trigger the notifier on all
 reboot/shutdown types?

From what I can tell, all the safe shutdown types go through notifier, however 
if you do something like:

echo o  /proc/sysrq-trigger

This will avoid the reboot notifier hook.  It is a question of how aggressively 
you want to catch all these cases or patch the kernel such that these holes 
provide notifications.

 If we decide to roll with this series, I will definitely merge this patch, 
 else I will remove the code since it is not used except for out of tree 
 patches.
 Even with a reboot notifier, you still need the logic of gdbstub_exit.
 So I doubt it makes sense to be removed, rather start to be used - finally.

You are correct about that, and it is actually used in the reboot notifier 
version.

Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 1/4] kgdb: x86: Return all segment registers also in 64-bit mode

[Jason Wessel]

On 03/19/2012 08:52 AM, Jan Kiszka wrote:
 On 2012-03-16 16:57, Jason Wessel wrote:
 The rest should be fine.   I can test this and add it to the merge queue with 
 the NUMREGBYTES change, unless you disagree.
 I don't disagree. :)

Sounds fine.  I added this to the merge queue for the 3.4 kernel.

Cheers,
Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 4/4] kgdb: x86: Detach gdb if machine shuts down or reboots

[Jason Wessel]

On 03/19/2012 08:49 AM, Jan Kiszka wrote:
 
 An arch-independent hook has its advantages, no question. Maybe we
 should just start this way and then evolved on top as needed.
 

Sounds good to me.  I added the reboot notifier patch into the merge queue for 
kgdb/kdb.

 I was wondering why those other archs do not use the notifier. Maybe one
 motivation is to avoid that too much code is excluded from the debugger
 by detaching too early. Could possibly be addressed by making
 detach-on-reboot runtime configurable.

There really isn't a whole lot of code between reboot hook invoked from 
kernel_restart_prepare(), and the place where the reset is invoked.  
Specifically it looked like:

usermodehelper_disable();
device_shutdown();
syscore_shutdown();
machine_restart(cmd);

Attached is the patch you asked for the conditional behavior with respect to 
the reboot hook.  This also implements the ability to stop on a reboot that is 
not a panic().

Cheers,
Jason.
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] KGDB / KDB Merge queue for 3.4

[Jason Wessel]

This is the merge queue for the 3.4 kernel, in case anyone wanted to further 
comment, before I send the pull request.

git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git for_linus

Thanks,
Jason.

---
Andrei Warkentin (1):
  KDB: Fix usability issues relating to the 'enter' key.

Jan Kiszka (2):
  kgdb: x86: Return all segment registers also in 64-bit mode
  kgdb: Respect that flush op is optional

Jason Wessel (2):
  kgdb,debug-core,gdbstub: Hook the reboot notifier for debugger detach
  kgdb,debug_core: add the ability to control the reboot notifier

 Documentation/DocBook/kgdb.tmpl |   17 +++
 arch/x86/include/asm/kgdb.h |   10 +++-
 arch/x86/kernel/kgdb.c  |6 ++-
 kernel/debug/debug_core.c   |   33 +
 kernel/debug/gdbstub.c  |   10 -
 kernel/debug/kdb/kdb_keyboard.c |   95 ++-
 kernel/debug/kdb/kdb_main.c |3 +
 kernel/debug/kdb/kdb_private.h  |7 +++
 8 files changed, 153 insertions(+), 28 deletions(-)

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 2/5] kgdb: Respect that flush op is optional

[Jason Wessel]

From: Jan Kiszka jan.kis...@siemens.com

Not all kgdb I/O drivers implement a flush operation. Adjust
gdbstub_exit accordingly.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/gdbstub.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/debug/gdbstub.c b/kernel/debug/gdbstub.c
index c22d8c2..5a15574 100644
--- a/kernel/debug/gdbstub.c
+++ b/kernel/debug/gdbstub.c
@@ -1129,5 +1129,6 @@ void gdbstub_exit(int status)
dbg_io_ops-write_char(hex_asc_lo(checksum));
 
/* make sure the output is flushed, lest the bootloader clobber it */
-   dbg_io_ops-flush();
+   if (dbg_io_ops-flush)
+   dbg_io_ops-flush();
 }
-- 
1.7.5.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 3/5] kgdb, debug-core, gdbstub: Hook the reboot notifier for debugger detach

[Jason Wessel]

The gdbstub and kdb should get detached if the system is rebooting.
Calling gdbstub_exit() will set the proper debug core state and send a
message to any debugger that is connected to correctly detach.

An attached debugger will receive the exit code from
include/linux/reboot.h based on SYS_HALT, SYS_REBOOT, etc...

Reported-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/debug_core.c |   17 +
 kernel/debug/gdbstub.c|7 +++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 0d7c087..3c1ad4e 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -41,6 +41,7 @@
 #include linux/delay.h
 #include linux/sched.h
 #include linux/sysrq.h
+#include linux/reboot.h
 #include linux/init.h
 #include linux/kgdb.h
 #include linux/kdb.h
@@ -784,6 +785,20 @@ void __init dbg_late_init(void)
kdb_init(KDB_INIT_FULL);
 }
 
+static int
+dbg_notify_reboot(struct notifier_block *this, unsigned long code, void *x)
+{
+   if (!dbg_kdb_mode)
+   gdbstub_exit(code);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block dbg_reboot_notifier = {
+   .notifier_call  = dbg_notify_reboot,
+   .next   = NULL,
+   .priority   = INT_MAX,
+};
+
 static void kgdb_register_callbacks(void)
 {
if (!kgdb_io_module_registered) {
@@ -791,6 +806,7 @@ static void kgdb_register_callbacks(void)
kgdb_arch_init();
if (!dbg_is_early)
kgdb_arch_late();
+   register_reboot_notifier(dbg_reboot_notifier);
atomic_notifier_chain_register(panic_notifier_list,
   kgdb_panic_event_nb);
 #ifdef CONFIG_MAGIC_SYSRQ
@@ -812,6 +828,7 @@ static void kgdb_unregister_callbacks(void)
 */
if (kgdb_io_module_registered) {
kgdb_io_module_registered = 0;
+   unregister_reboot_notifier(dbg_reboot_notifier);
atomic_notifier_chain_unregister(panic_notifier_list,
   kgdb_panic_event_nb);
kgdb_arch_exit();
diff --git a/kernel/debug/gdbstub.c b/kernel/debug/gdbstub.c
index 5a15574..ce615e0 100644
--- a/kernel/debug/gdbstub.c
+++ b/kernel/debug/gdbstub.c
@@ -,6 +,13 @@ void gdbstub_exit(int status)
unsigned char checksum, ch, buffer[3];
int loop;
 
+   if (!kgdb_connected)
+   return;
+   kgdb_connected = 0;
+
+   if (!dbg_io_ops || dbg_kdb_mode)
+   return;
+
buffer[0] = 'W';
buffer[1] = hex_asc_hi(status);
buffer[2] = hex_asc_lo(status);
-- 
1.7.5.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 5/5] kgdb, debug_core: add the ability to control the reboot notifier

[Jason Wessel]

Sometimes it is desirable to stop the kernel debugger before allowing
a system to reboot either with kdb or kgdb.  This patch adds the
ability to turn the reboot notifier on and off or enter the debugger
and stop kernel execution before rebooting.

It is possible to change the setting after booting the kernel with the
following:

echo 1  /sys/module/debug_core/parameters/kgdbreboot

It is also possible to change this setting using kdb / kgdb to
manipulate the variable directly.

Using KDB:
   mm kgdbreboot 1

Using gdb:
   set kgdbreboot=1

Reported-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 Documentation/DocBook/kgdb.tmpl |   17 +
 kernel/debug/debug_core.c   |   16 
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
index d71b57f..4ee4ba3 100644
--- a/Documentation/DocBook/kgdb.tmpl
+++ b/Documentation/DocBook/kgdb.tmpl
@@ -362,6 +362,23 @@
/para
   /para
   /sect1
+   sect1 id=kgdbreboot
+   titleRun time parameter: kgdbreboot/title
+   para The kgdbreboot feature allows you to change how the debugger
+   deals with the reboot notification.  You have 3 choices for the
+   behavior.  The default behavior is always set to 0./para
+   orderedlist
+   listitemparaecho -1  
/sys/module/debug_core/parameters/kgdbreboot/para
+   paraIgnore the reboot notification entirely./para
+   /listitem
+   listitemparaecho 0  /sys/module/debug_core/parameters/kgdbreboot/para
+   paraSend the detach message to any attached debugger client./para
+   /listitem
+   listitemparaecho 1  /sys/module/debug_core/parameters/kgdbreboot/para
+   paraEnter the debugger on reboot notify./para
+   /listitem
+   /orderedlist
+  /sect1
   /chapter
   chapter id=usingKDB
   titleUsing kdb/title
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 3c1ad4e..3f88a45 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -76,6 +76,8 @@ static intexception_level;
 struct kgdb_io *dbg_io_ops;
 static DEFINE_SPINLOCK(kgdb_registration_lock);
 
+/* Action for the reboot notifiter, a global allow kdb to change it */
+static int kgdbreboot;
 /* kgdb console driver is loaded */
 static int kgdb_con_registered;
 /* determine if kgdb console output should be used */
@@ -97,6 +99,7 @@ static int __init opt_kgdb_con(char *str)
 early_param(kgdbcon, opt_kgdb_con);
 
 module_param(kgdb_use_con, int, 0644);
+module_param(kgdbreboot, int, 0644);
 
 /*
  * Holds information about breakpoints in a kernel. These breakpoints are
@@ -788,8 +791,21 @@ void __init dbg_late_init(void)
 static int
 dbg_notify_reboot(struct notifier_block *this, unsigned long code, void *x)
 {
+   /*
+* Take the following action on reboot notify depending on value:
+*1 == Enter debugger
+*0 == [the default] detatch debug client
+*   -1 == Do nothing... and use this until the board resets
+*/
+   switch (kgdbreboot) {
+   case 1:
+   kgdb_breakpoint();
+   case -1:
+   goto done;
+   }
if (!dbg_kdb_mode)
gdbstub_exit(code);
+done:
return NOTIFY_DONE;
 }
 
-- 
1.7.5.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 4/5] KDB: Fix usability issues relating to the 'enter' key.

[Jason Wessel]

From: Andrei Warkentin andrey.warken...@gmail.com

This fixes the following problems:
1) Typematic-repeat of 'enter' gives warning message
   and leaks make/break if KDB exits. Repeats
   look something like 0x1c 0x1c  0x9c
2) Use of 'keypad enter' gives warning message and
   leaks the ENTER break/make code out if KDB exits.
   KP ENTER repeats look someting like 0xe0 0x1c
   0xe0 0x1c ... 0xe0 0x9c.
3) Lag on the order of seconds between break and make when
   expecting the enter break code. Seen under virtualized
   environments such as VMware ESX.

The existing special enter handler tries to glob the enter break code,
but this fails if the other (KP) enter was used, or if there was a key
repeat. It also fails if you mashed some keys along with enter, and
you ended up with a non-enter make or non-enter break code coming
after the enter make code. So first, we modify the handler to handle
these cases. But performing these actions on every enter is annoying
since now you can't hold ENTER down to scroll mored messages in
KDB. Since this special behaviour is only necessary to handle the
exiting KDB ('g' + ENTER) without leaking scancodes to the OS.  This
cleanup needs to get executed anytime the kdb_main loop exits.

Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked.

Cc: Andrei Warkentin andr...@vmware.com
[jason.wes...@windriver.com: move cleanup calls to kdb_main.c]
Signed-off-by: Andrei Warkentin andrey.warken...@gmail.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/kdb/kdb_keyboard.c |   95 ++-
 kernel/debug/kdb/kdb_main.c |3 +
 kernel/debug/kdb/kdb_private.h  |7 +++
 3 files changed, 83 insertions(+), 22 deletions(-)

diff --git a/kernel/debug/kdb/kdb_keyboard.c b/kernel/debug/kdb/kdb_keyboard.c
index 4bca634..118527a 100644
--- a/kernel/debug/kdb/kdb_keyboard.c
+++ b/kernel/debug/kdb/kdb_keyboard.c
@@ -25,6 +25,7 @@
 #define KBD_STAT_MOUSE_OBF 0x20/* Mouse output buffer full */
 
 static int kbd_exists;
+static int kbd_last_ret;
 
 /*
  * Check if the keyboard controller has a keypress for us.
@@ -90,8 +91,11 @@ int kdb_get_kbd_char(void)
return -1;
}
 
-   if ((scancode  0x80) != 0)
+   if ((scancode  0x80) != 0) {
+   if (scancode == 0x9c)
+   kbd_last_ret = 0;
return -1;
+   }
 
scancode = 0x7f;
 
@@ -178,35 +182,82 @@ int kdb_get_kbd_char(void)
return -1;  /* ignore unprintables */
}
 
-   if ((scancode  0x7f) == 0x1c) {
-   /*
-* enter key.  All done.  Absorb the release scancode.
-*/
+   if (scancode == 0x1c) {
+   kbd_last_ret = 1;
+   return 13;
+   }
+
+   return keychar  0xff;
+}
+EXPORT_SYMBOL_GPL(kdb_get_kbd_char);
+
+/*
+ * Best effort cleanup of ENTER break codes on leaving KDB. Called on
+ * exiting KDB, when we know we processed an ENTER or KP ENTER scan
+ * code.
+ */
+void kdb_kbd_cleanup_state(void)
+{
+   int scancode, scanstatus;
+
+   /*
+* Nothing to clean up, since either
+* ENTER was never pressed, or has already
+* gotten cleaned up.
+*/
+   if (!kbd_last_ret)
+   return;
+
+   kbd_last_ret = 0;
+   /*
+* Enter key. Need to absorb the break code here, lest it gets
+* leaked out if we exit KDB as the result of processing 'g'.
+*
+* This has several interesting implications:
+* + Need to handle KP ENTER, which has break code 0xe0 0x9c.
+* + Need to handle repeat ENTER and repeat KP ENTER. Repeats
+*   only get a break code at the end of the repeated
+*   sequence. This means we can't propagate the repeated key
+*   press, and must swallow it away.
+* + Need to handle possible PS/2 mouse input.
+* + Need to handle mashed keys.
+*/
+
+   while (1) {
while ((inb(KBD_STATUS_REG)  KBD_STAT_OBF) == 0)
-   ;
+   cpu_relax();
 
/*
-* Fetch the scancode
+* Fetch the scancode.
 */
scancode = inb(KBD_DATA_REG);
scanstatus = inb(KBD_STATUS_REG);
 
-   while (scanstatus  KBD_STAT_MOUSE_OBF) {
-   scancode = inb(KBD_DATA_REG);
-   scanstatus = inb(KBD_STATUS_REG);
-   }
+   /*
+* Skip mouse input.
+*/
+   if (scanstatus  KBD_STAT_MOUSE_OBF)
+   continue;
 
-   if (scancode != 0x9c) {
-   /*
-* Wasn't an enter-release,  why not?
-*/
-   kdb_printf(kdb: expected enter got 0x%x status 0x%x\n,
-  scancode

Re: [Kgdb-bugreport] [PATCH 4/4] kgdb: x86: Detach gdb if machine shuts down or reboots

[Jason Wessel]

On 03/20/2012 06:18 AM, Sergei Shtylyov wrote:
 Hello.

 On 20-03-2012 5:00, Jason Wessel wrote:

 An arch-independent hook has its advantages, no question. Maybe we
 should just start this way and then evolved on top as needed.
 Sounds good to me.  I added the reboot notifier patch into the merge queue 
 for kgdb/kdb.
 I was wondering why those other archs do not use the notifier. Maybe one
 motivation is to avoid that too much code is excluded from the debugger
 by detaching too early. Could possibly be addressed by making
 detach-on-reboot runtime configurable.
 There really isn't a whole lot of code between reboot hook invoked from 
 kernel_restart_prepare(),
 and the place where the reset is invoked.  Specifically it looked like:
  usermodehelper_disable();
  device_shutdown();
  syscore_shutdown();
  machine_restart(cmd);
 Attached is the patch you asked for the conditional behavior with respect to 
 the reboot hook.
 You forgot to attach it?

Source Forge [kgdb mailling list] is eating attachments.  I had definitely 
attached it.  See: 

https://lkml.org/lkml/2012/3/19/735

I also included this patch in the potential merge queue as patch 5 of 5, sent 
to the kgdb mailing list.

http://sourceforge.net/mailarchive/message.php?msg_id=29008292

Jason.


Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] Fwd: [PATCH] kdb: Avoid using dbg_io_ops until it is initialized

[Jason Wessel]

On 03/20/2012 11:34 AM, Tim Bird wrote:
 Jason,

 This patch has apparently fallen through the cracks.  Can you please apply?
 This fixes a kernel panic for a use case where I'm setting a breakpoint
 from kdb_cmds on kernel startup.  In this case, without this patch
 dbg_io_ops is used before it is initialized.

Many thanks Tim.

I'll review/regression test this and add it to the merge queue.   I found 
another patch from you in the same week from last year that I will also review. 
 I am not exactly sure why these never made it to my review list, but what once 
was lost is now found.

Cheers,
Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] kdb: Add message about CONFIG_DEBUG_RODATA on failure to install breakpoint

[Jason Wessel]

On 09/21/2011 03:07 PM, Tim Bird wrote:
 On x86, if CONFIG_DEBUG_RODATA is set, one cannot set breakpoints
 via KDB.  Apparently this is a well-known problem, as at least one 
 distribution
 now ships with both KDB enabled and CONFIG_DEBUG_RODATA=y for security 
 reasons.
 
 This patch just adds an extra printk message to the breakpoint failure case,
 in order to provide some useful diagnostics to the user.
 

The patch is definitely the right idea.  I believe we should try and tell the 
whole story and only print the message for the type of breakpoint that fails.  
It is absolutely the case that you can still use kdb/kdb without recompiling 
the kernel.

I propose a slightly different implementation below.


---

Subject: [PATCH] kdb: Add message about CONFIG_DEBUG_RODATA on failure to 
install breakpoint

When the kernel config option CONFIG_DEBUG_RODATA=y is set on x86
software breakpoints are not available to KDB.  The constraints to
debug kernel are often at odds with security protections for a kernel
and several OS distributions ship with both KDB enabled and
CONFIG_DEBUG_RODATA=y.

This patch adds an printk message to the breakpoint failure case,
in order to provide suggestions about how to use the debugger.

Reported-by: Tim Bird tim.b...@am.sony.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/kdb/kdb_bp.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/kernel/debug/kdb/kdb_bp.c b/kernel/debug/kdb/kdb_bp.c
index 20059ef..8418c2f 100644
--- a/kernel/debug/kdb/kdb_bp.c
+++ b/kernel/debug/kdb/kdb_bp.c
@@ -153,7 +153,13 @@ static int _kdb_bp_install(struct pt_regs *regs, kdb_bp_t 
*bp)
} else {
kdb_printf(%s: failed to set breakpoint at 0x%lx\n,
   __func__, bp-bp_addr);
+#ifdef CONFIG_DEBUG_RODATA
+   if (!bp-bp_type) {
+   kdb_printf(Software breakpoints are unavailable.\n
+Change the kernel CONFIG_DEBUG_RODATA=n\n
+OR use hw breakpoints: help bph\n);
+   }
+#endif
return 1;
}
return 0;

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] kdb: Avoid using dbg_io_ops until it is initialized

[Jason Wessel]

On 09/21/2011 03:19 PM, Tim Bird wrote:
 This fixes a bug with setting a breakpoint during kdb initialization
 (from kdb_cmds). Any call to kdb_printf() before the initialization
 of the kgdboc serial console driver (which happens much later during
 bootup than kdb_init), results in kernel panic due to the use of
 dbg_io_ops before it is initialized.

I added this patch to the merge queue for the 3.4 kernel.

In the test and review of this patch, I thought there might be another
race condition with kdb pager, but this is not the case.  The run time
validation shows that the kdb pager can only get activated by entering
and configuring the kdb shell and it is turned off on exit, so we are
all set and no further changes are needed.

Thanks,
Jason.



--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 0/2] Fix KGDB to work with CONFIG_DEBUG_RODATA using kprobe API

[Jason Wessel]

The inability to use software breakpoints on a kernel built with
CONFIG_DEBUG_RODATA has been a problem for quite a few years.  The
kprobes API has been working around this limitation for a long
time. This patch set changes the debug_core to use the kprobe
breakpoint API directly for a kernel compiled with CONFIG_DEBUG_RODATA.

Comments are welcome of course.

Thanks,
Jason.

---
Jason Wessel (2):
  kgdb,debug_core: pass the breakpoint struct instead of address and memory
  kgdb,debug_core,kgdbts: End DEBUG_RODATA limitation using kprobe 
breakpoints

 drivers/misc/kgdbts.c |   13 --
 include/linux/kgdb.h  |7 ++-
 kernel/debug/debug_core.c |   93 ++--
 3 files changed, 67 insertions(+), 46 deletions(-)

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 2/2] kgdb, debug_core, kgdbts: End DEBUG_RODATA limitation using kprobe breakpoints

[Jason Wessel]

There has long been a limitation using software breakpoints with a
kernel compiled with CONFIG_DEBUG_RODATA.  The kprobe breakpoint code
has its own text_poke() function which accommodates writing a
breakpoint into a read-only page.  The debug_core can make use of the
text_poke() capabilities by using the kprobes API, specifically
arch_arm_kprobe() and arch_disarm_kprobe().  For now it is safe to use
a single statically allocated kprobe structure to call the kprobes API
because the debug_core breakpoint API is only used when the kernel is
in the debug state.

The debug_core will first attempt to use the traditional
probe_kernel_write(), and next try using a kprobe breakpoint.  The
kgdb test suite was updated to run all the software breakpoint tests
when using a kernel with built with CONFIG_DEBUG_RODATA.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 drivers/misc/kgdbts.c |   13 -
 include/linux/kgdb.h  |3 ++-
 kernel/debug/debug_core.c |   40 +++-
 3 files changed, 41 insertions(+), 15 deletions(-)

diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 3f7ad83..672b4a5 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -940,19 +940,6 @@ static void kgdbts_run_tests(void)
run_nmi_sleep_test(nmi_sleep);
}
 
-#ifdef CONFIG_DEBUG_RODATA
-   /* Until there is an api to write to read-only text segments, use
-* HW breakpoints for the remainder of any tests, else print a
-* failure message if hw breakpoints do not work.
-*/
-   if (!(arch_kgdb_ops.flags  KGDB_HW_BREAKPOINT  hwbreaks_ok)) {
-   eprintk(kgdbts: HW breakpoints do not work,
-   skipping remaining tests\n);
-   return;
-   }
-   force_hwbrks = 1;
-#endif /* CONFIG_DEBUG_RODATA */
-
/* If the do_fork test is run it will be the last test that is
 * executed because a kernel thread will be spawned at the very
 * end to unregister the debug hooks.
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index e5d689c..48f17d2 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -63,7 +63,8 @@ enum kgdb_bptype {
BP_HARDWARE_BREAKPOINT,
BP_WRITE_WATCHPOINT,
BP_READ_WATCHPOINT,
-   BP_ACCESS_WATCHPOINT
+   BP_ACCESS_WATCHPOINT,
+   BP_KPROBE_BREAKPOINT,
 };
 
 enum kgdb_bpstate {
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index a7e52ca..9051844 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -49,6 +49,7 @@
 #include linux/smp.h
 #include linux/mm.h
 #include linux/rcupdate.h
+#include linux/kprobes.h
 
 #include asm/cacheflush.h
 #include asm/byteorder.h
@@ -108,6 +109,13 @@ module_param(kgdbreboot, int, 0644);
 static struct kgdb_bkptkgdb_break[KGDB_MAX_BREAKPOINTS] = {
[0 ... KGDB_MAX_BREAKPOINTS-1] = { .state = BP_UNDEFINED }
 };
+/*
+ * probe_write_tmp is used to r/w breakpoints with the kprobe
+ * interface, it is not protected for reentrancy
+ */
+#if defined(CONFIG_KPROBES)  defined(CONFIG_DEBUG_RODATA)
+static struct kprobe probe_write_tmp;
+#endif /* CONFIG_KPROBES  CONFIG_DEBUG_RODATA */
 
 /*
  * The CPU# of the active CPU, or -1 if none:
@@ -165,17 +173,48 @@ int __weak kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 {
int err;
 
+   bpt-type = BP_BREAKPOINT;
err = probe_kernel_read(bpt-saved_instr, (char *)bpt-bpt_addr,
BREAK_INSTR_SIZE);
if (err)
return err;
err = probe_kernel_write((char *)bpt-bpt_addr,
 arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE);
+#if defined(CONFIG_KPROBES)  defined(CONFIG_DEBUG_RODATA)
+   if (!err)
+   return err;
+   probe_write_tmp.addr = (kprobe_opcode_t *)bpt-bpt_addr;
+   arch_arm_kprobe(probe_write_tmp);
+   err = probe_kernel_read(probe_write_tmp.opcode, (char *)bpt-bpt_addr,
+   BREAK_INSTR_SIZE);
+   if (err)
+   return err;
+   if (memcmp(probe_write_tmp.opcode, arch_kgdb_ops.gdb_bpt_instr,
+  BREAK_INSTR_SIZE))
+   return -EINVAL;
+   bpt-type = BP_KPROBE_BREAKPOINT;
+#endif /* CONFIG_KPROBES  CONFIG_DEBUG_RODATA */
return err;
 }
 
 int __weak kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
 {
+#if defined(CONFIG_KPROBES)  defined(CONFIG_DEBUG_RODATA)
+   int err;
+
+   if (bpt-type != BP_KPROBE_BREAKPOINT)
+   goto knl_write;
+   probe_write_tmp.addr = (kprobe_opcode_t *)bpt-bpt_addr;
+   memcpy(probe_write_tmp.opcode, bpt-saved_instr, BREAK_INSTR_SIZE);
+   arch_disarm_kprobe(probe_write_tmp);
+   err = probe_kernel_read(probe_write_tmp.opcode, (char *)bpt-bpt_addr,
+   BREAK_INSTR_SIZE);
+   if (err ||
+   memcmp(probe_write_tmp.opcode, bpt

[Kgdb-bugreport] [PATCH 1/2] kgdb, debug_core: pass the breakpoint struct instead of address and memory

[Jason Wessel]

There is extra state information that needs to be exposed in the
kgdb_bpt structure for tracking whether or not a breakpoint was
installed via a kprobe or via a probe_kernel_write().  In order to
access the structure it needs to be passed to the
kgdb_arch_set_breakpoint() and kgdb_arch_remove_breakpoint().

A future commit adds the logic for the kprobe breakpoint type.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 include/linux/kgdb.h  |4 +-
 kernel/debug/debug_core.c |   53 
 2 files changed, 26 insertions(+), 31 deletions(-)

diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index fa39183..e5d689c 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -207,8 +207,8 @@ extern void kgdb_arch_set_pc(struct pt_regs *regs, unsigned 
long pc);
 
 /* Optional functions. */
 extern int kgdb_validate_break_address(unsigned long addr);
-extern int kgdb_arch_set_breakpoint(unsigned long addr, char *saved_instr);
-extern int kgdb_arch_remove_breakpoint(unsigned long addr, char *bundle);
+extern int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt);
+extern int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt);
 
 /**
  * kgdb_arch_late - Perform any architecture specific initalization.
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 3f88a45..a7e52ca 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -161,37 +161,39 @@ early_param(nokgdbroundup, opt_nokgdbroundup);
  * Weak aliases for breakpoint management,
  * can be overriden by architectures when needed:
  */
-int __weak kgdb_arch_set_breakpoint(unsigned long addr, char *saved_instr)
+int __weak kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 {
int err;
 
-   err = probe_kernel_read(saved_instr, (char *)addr, BREAK_INSTR_SIZE);
+   err = probe_kernel_read(bpt-saved_instr, (char *)bpt-bpt_addr,
+   BREAK_INSTR_SIZE);
if (err)
return err;
-
-   return probe_kernel_write((char *)addr, arch_kgdb_ops.gdb_bpt_instr,
- BREAK_INSTR_SIZE);
+   err = probe_kernel_write((char *)bpt-bpt_addr,
+arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE);
+   return err;
 }
 
-int __weak kgdb_arch_remove_breakpoint(unsigned long addr, char *bundle)
+int __weak kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
 {
-   return probe_kernel_write((char *)addr,
- (char *)bundle, BREAK_INSTR_SIZE);
+   return probe_kernel_write((char *)bpt-bpt_addr,
+ (char *)bpt-saved_instr, BREAK_INSTR_SIZE);
 }
 
 int __weak kgdb_validate_break_address(unsigned long addr)
 {
-   char tmp_variable[BREAK_INSTR_SIZE];
+   struct kgdb_bkpt tmp;
int err;
-   /* Validate setting the breakpoint and then removing it.  In the
+   /* Validate setting the breakpoint and then removing it.  If the
 * remove fails, the kernel needs to emit a bad message because we
 * are deep trouble not being able to put things back the way we
 * found them.
 */
-   err = kgdb_arch_set_breakpoint(addr, tmp_variable);
+   tmp.bpt_addr = addr;
+   err = kgdb_arch_set_breakpoint(tmp);
if (err)
return err;
-   err = kgdb_arch_remove_breakpoint(addr, tmp_variable);
+   err = kgdb_arch_remove_breakpoint(tmp);
if (err)
printk(KERN_ERR KGDB: Critical breakpoint error, kernel 
   memory destroyed at: %lx, addr);
@@ -235,7 +237,6 @@ static void kgdb_flush_swbreak_addr(unsigned long addr)
  */
 int dbg_activate_sw_breakpoints(void)
 {
-   unsigned long addr;
int error;
int ret = 0;
int i;
@@ -244,16 +245,15 @@ int dbg_activate_sw_breakpoints(void)
if (kgdb_break[i].state != BP_SET)
continue;
 
-   addr = kgdb_break[i].bpt_addr;
-   error = kgdb_arch_set_breakpoint(addr,
-   kgdb_break[i].saved_instr);
+   error = kgdb_arch_set_breakpoint(kgdb_break[i]);
if (error) {
ret = error;
-   printk(KERN_INFO KGDB: BP install failed: %lx, addr);
+   printk(KERN_INFO KGDB: BP install failed: %lx,
+  kgdb_break[i].bpt_addr);
continue;
}
 
-   kgdb_flush_swbreak_addr(addr);
+   kgdb_flush_swbreak_addr(kgdb_break[i].bpt_addr);
kgdb_break[i].state = BP_ACTIVE;
}
return ret;
@@ -302,7 +302,6 @@ int dbg_set_sw_break(unsigned long addr)
 
 int dbg_deactivate_sw_breakpoints(void)
 {
-   unsigned long addr;
int error;
int ret = 0;
int i;
@@ -310,15 +309,14 @@ int dbg_deactivate_sw_breakpoints(void)
for (i = 0; i

Re: [Kgdb-bugreport] [PATCH 2/2] kgdb, debug_core, kgdbts: End DEBUG_RODATA limitation using kprobe breakpoints

[Jason Wessel]

On 03/21/2012 09:53 PM, Masami Hiramatsu wrote:
 (2012/03/22 2:55), Jason Wessel wrote:
 There has long been a limitation using software breakpoints with a
 kernel compiled with CONFIG_DEBUG_RODATA.  The kprobe breakpoint code
 has its own text_poke() function which accommodates writing a
 breakpoint into a read-only page.  The debug_core can make use of the
 text_poke() capabilities by using the kprobes API, specifically
 arch_arm_kprobe() and arch_disarm_kprobe().  For now it is safe to use
 a single statically allocated kprobe structure to call the kprobes API
 because the debug_core breakpoint API is only used when the kernel is
 in the debug state.
 
 You might misunderstand it. arch_*_kprobe() are not open APIs.
 Those are kprobes internal APIs (which means that those functions
 should be used only by kprobes).
 


I was looking for an interface that solved the problem, without having
to use text_poke directly which is arch specific.  Eventually I would
like to use the kprobes high level API, but it cannot not be used
without taking a mutex presently.  This is a separate problem to deal
with at a later time, because the generic use of kprobes would be
aimed at having robust single stepping.

 
 The debug_core will first attempt to use the traditional
 probe_kernel_write(), and next try using a kprobe breakpoint.  The
 kgdb test suite was updated to run all the software breakpoint tests
 when using a kernel with built with CONFIG_DEBUG_RODATA.

 Signed-off-by: Jason Wessel jason.wes...@windriver.com
 
 Nak.
 
 No, please don't use kprobes internal function this way, because
 you can't ensure that the arch_arm_kprobe() has no side-effect.
 
 Why don't you use text_poke()? I see that the text_poke()
 is only for x86, but you already have arch/x86/kernel/kgdb.c for
 making your own wrapper function.

I will use the arch specific provision to override the
kgdb_arch_set_breakpoint() and use the text_poke() directly.

Eventually I would like to use the same software breakpoint
reservation system as kprobes, and that would happen if kgdb ever
starts using kprobes for single stepping.  A few years back we solved
the problem for hardware breakpoints reservations where the kernel
debugger, perf, ptrace, and kprobes all play nice.


Thanks,
Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] kdb: Avoid using dbg_io_ops until it is initialized

[Jason Wessel]

On 03/22/2012 01:30 AM, Dan Carpenter wrote:
 Hello Tim Bird,

 This is a semi-automatic email about new static checker warnings.

 The patch 3492c71d374c: kdb: Avoid using dbg_io_ops until it is 
 initialized from Sep 21, 2011, leads to the following Smatch 
 complaint:

 kernel/debug/kdb/kdb_io.c:746 vkdb_printf()
error: we previously assumed 'dbg_io_ops' could be null (see line 692)

 kernel/debug/kdb/kdb_io.c
691} else {
692if (dbg_io_ops  !dbg_io_ops-is_console) {
 ^^
 New check.

693len = strlen(kdb_buffer);
694cp = kdb_buffer;
695while (len--) {
696dbg_io_ops-write_char(*cp);
697cp++;
698}
699}

   [snip]

742
743kdb_input_flush();
744c = console_drivers;
745
746if (!dbg_io_ops-is_console) {
  ^^
 Old dereference.  Should we check here as well?

I had the same question when I reviewed and tested this code.  This section of 
code is protected by the kdb pager block, where dbg_io_ops cannot be null.

Should I be adding a comment to that effect, or just pay the price for the null 
check to squelch the warning?

Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 2/2] kgdb, debug_core, kgdbts: End DEBUG_RODATA limitation using kprobe breakpoints

[Jason Wessel]

On 03/23/2012 09:08 AM, Masami Hiramatsu wrote:
 (2012/03/22 20:57), Jason Wessel wrote:
 I will use the arch specific provision to override the
 kgdb_arch_set_breakpoint() and use the text_poke() directly.
 
 Thanks! that's what I meant. You can use __weak attribute.
 

I created and tested a patch yesterday which is show below.  I will
post a new series at some point soon which addresses this problem as
well as a number of problems found with the kgdb test suite.

Cheers,
Jason.


Subject: [PATCH] x86,kgdb: End DEBUG_RODATA limitation using text_poke()

There has long been a limitation using software breakpoints with a
kernel compiled with CONFIG_DEBUG_RODATA.  The kprobes code has long
used the text_poke() function which accommodates writing a breakpoint
into a read-only page.  The x86 arch can override the default
breakpoint install remove routines and make use of the text_poke()
code that comes from the x86 alternatives.

The x86 arch will first attempt to use the traditional
probe_kernel_write(), and next try using a the text_poke() function.
The break point install method is tracked such that the correct break
point removal routine will get called later on.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 arch/x86/kernel/kgdb.c |   46 ++
 include/linux/kgdb.h   |3 ++-
 2 files changed, 48 insertions(+), 1 deletion(-)

--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -63,7 +63,8 @@ enum kgdb_bptype {
BP_HARDWARE_BREAKPOINT,
BP_WRITE_WATCHPOINT,
BP_READ_WATCHPOINT,
-   BP_ACCESS_WATCHPOINT
+   BP_ACCESS_WATCHPOINT,
+   BP_POKE_BREAKPOINT,
 };
 
 enum kgdb_bpstate {
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -742,6 +742,52 @@ void kgdb_arch_set_pc(struct pt_regs *re
regs-ip = ip;
 }
 
+int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
+{
+   int err;
+   char opc[BREAK_INSTR_SIZE];
+
+   bpt-type = BP_BREAKPOINT;
+   err = probe_kernel_read(bpt-saved_instr, (char *)bpt-bpt_addr,
+   BREAK_INSTR_SIZE);
+   if (err)
+   return err;
+   err = probe_kernel_write((char *)bpt-bpt_addr,
+arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE);
+#ifdef CONFIG_DEBUG_RODATA
+   if (!err)
+   return err;
+   text_poke((void *)bpt-bpt_addr, arch_kgdb_ops.gdb_bpt_instr,
+ BREAK_INSTR_SIZE);
+   err = probe_kernel_read(opc, (char *)bpt-bpt_addr, BREAK_INSTR_SIZE);
+   if (err)
+   return err;
+   if (memcmp(opc, arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE))
+   return -EINVAL;
+   bpt-type = BP_POKE_BREAKPOINT;
+#endif /* CONFIG_DEBUG_RODATA */
+   return err;
+}
+
+int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
+{
+#ifdef CONFIG_DEBUG_RODATA
+   int err;
+   char opc[BREAK_INSTR_SIZE];
+
+   if (bpt-type != BP_POKE_BREAKPOINT)
+   goto knl_write;
+   text_poke((void *)bpt-bpt_addr, bpt-saved_instr, BREAK_INSTR_SIZE);
+   err = probe_kernel_read(opc, (char *)bpt-bpt_addr, BREAK_INSTR_SIZE);
+   if (err || memcmp(opc, bpt-saved_instr, BREAK_INSTR_SIZE))
+   goto knl_write;
+   return err;
+knl_write:
+#endif /* CONFIG_DEBUG_RODATA */
+   return probe_kernel_write((char *)bpt-bpt_addr,
+ (char *)bpt-saved_instr, BREAK_INSTR_SIZE);
+}
+
 struct kgdb_arch arch_kgdb_ops = {
/* Breakpoint instruction: */
.gdb_bpt_instr  = { 0xcc },


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [GIT PULL] KGDB/KDB updates for the 3.4 merge window

[Jason Wessel]

The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:

  Linux 3.3 (2012-03-18 16:15:34 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linus-3.4-rc1

for you to fetch changes up to 1ba0c1720eb0de2d0f3abf84c0b128d10af520d1:

  kdb: Add message about CONFIG_DEBUG_RODATA on failure to install breakpoint 
(2012-03-22 15:07:16 -0500)


Fixes:
- Fix KDB keyboard repeat scan codes and leaked keyboard events
- Fix kernel crash with kdb_printf() for users who compile new kdb_printf()'s
  in early code
- Return all segment registers to gdb on x86_64
Features:
- KDB/KGDB hook the reboot notifier and end user can control if it stops,
  detaches or does nothing (updated docs as well)
- Notify users who use CONFIG_DEBUG_RODATA to use hw breakpoints


Andrei Warkentin (1):
  KDB: Fix usability issues relating to the 'enter' key.

Jan Kiszka (2):
  kgdb: x86: Return all segment registers also in 64-bit mode
  kgdb: Respect that flush op is optional

Jason Wessel (3):
  kgdb,debug-core,gdbstub: Hook the reboot notifier for debugger detach
  kgdb,debug_core: add the ability to control the reboot notifier
  kdb: Add message about CONFIG_DEBUG_RODATA on failure to install 
breakpoint

Tim Bird (1):
  kdb: Avoid using dbg_io_ops until it is initialized

 Documentation/DocBook/kgdb.tmpl |   17 +++
 arch/x86/include/asm/kgdb.h |   10 +++--
 arch/x86/kernel/kgdb.c  |6 ++-
 kernel/debug/debug_core.c   |   33 ++
 kernel/debug/gdbstub.c  |   10 -
 kernel/debug/kdb/kdb_bp.c   |7 +++
 kernel/debug/kdb/kdb_io.c   |2 +-
 kernel/debug/kdb/kdb_keyboard.c |   95 ++-
 kernel/debug/kdb/kdb_main.c |3 ++
 kernel/debug/kdb/kdb_private.h  |7 +++
 10 files changed, 161 insertions(+), 29 deletions(-)

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] kdb: Avoid using dbg_io_ops until it is initialized

[Jason Wessel]

On 03/23/2012 11:39 AM, Tim Bird wrote:
 On 03/22/2012 05:06 AM, Jason Wessel wrote:
 On 03/22/2012 01:30 AM, Dan Carpenter wrote:
 Hello Tim Bird,

 This is a semi-automatic email about new static checker warnings.

 The patch 3492c71d374c: kdb: Avoid using dbg_io_ops until it is 
 initialized from Sep 21, 2011, leads to the following Smatch 
 complaint:

 kernel/debug/kdb/kdb_io.c:746 vkdb_printf()
  error: we previously assumed 'dbg_io_ops' could be null (see line 692)

 kernel/debug/kdb/kdb_io.c
691  } else {
692  if (dbg_io_ops  !dbg_io_ops-is_console) {
 ^^
 New check.

693  len = strlen(kdb_buffer);
694  cp = kdb_buffer;
695  while (len--) {
696  dbg_io_ops-write_char(*cp);
697  cp++;
698  }
699  }

 [snip]

742  
743  kdb_input_flush();
744  c = console_drivers;
745  
746  if (!dbg_io_ops-is_console) {
  ^^
 Old dereference.  Should we check here as well?
 I had the same question when I reviewed and tested this code.  This section 
 of code is protected by the kdb pager block, where dbg_io_ops cannot be null.

 Should I be adding a comment to that effect, or just pay the price for the 
 null check to squelch the warning?
 I double-checked this in my code, and was surprised to see that
 I already had a null check here.  Hmm...  There's something wrong
 with my patch submission skils, that this didn't get included
 in my original patch. :-(

 I have to admit that the states that affect this function are somewhat
 baffling to me.  I hate adding extra code, but it's probably safest to
 add the check.  We know that during bootup dbg_io_ops spends some time
 being null.  I would hate to see a future modification to some unrelated state
 (e.g. some change to the kdb pager block, which looks completely unrelated),
 allow us to hit this problem again in the future.

 My vote would be to add the check.

No problem.  I'll make a simple patch, post it, and put it in the queue, to 
clean it up before 3.4-rc2.

Cheers,
Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 2/2] kgdb, debug_core, kgdbts: End DEBUG_RODATA limitation using kprobe breakpoints

[Jason Wessel]

On 03/26/2012 04:46 AM, Masami Hiramatsu wrote:
 (2012/03/23 23:38), Jason Wessel wrote:
 On 03/23/2012 09:08 AM, Masami Hiramatsu wrote:
 (2012/03/22 20:57), Jason Wessel wrote:
 I will use the arch specific provision to override the
 kgdb_arch_set_breakpoint() and use the text_poke() directly.

 Thanks! that's what I meant. You can use __weak attribute.


 I created and tested a patch yesterday which is show below.  I will
 post a new series at some point soon which addresses this problem as
 well as a number of problems found with the kgdb test suite.
 
 Yeah, that's better.
 
 BTW, I'm not sure the policy of kgdb about mutex, but it seems
 that you need to hold a text_mutex when you call the text_poke()
 since it uses a fixmap page-area for mapping read-only text page
 to writable page. So, without locking (at least ensuring no one
 using) text_mutex, it seems not be safe. (some other code may be
 trying to change the code by using same fixmap pages)

Thank you very much for the advice.  I had run the kgdb mutex
validation which checks for mutex's taken any time I change the kgdb
code and it passed.  However, this did not check for incorrect usage
where the debug core should really be taking a mutex to prevent
corruption.  The comments in the text_poke code clearly indicate a
caller must hold the text_mutex().

I started looking through all the code that uses text_mutex and what
it actually protects.  It looked like it is probably possible to make
things re-entrant in order to deal with the case where debugger changes
a location with a fixmap when kernel execution is stopped.  I am not
convinced this is a good idea, given complexity of the code, vs the
small number of users and the likely hood of interference being on the
low side.  For now, I am not going to pursue making any kind of
changes with fix map or the text_mutex protected regions.  Today there
are only 3 users of the text_mutex, SMP alternatives, jump labels
updates, and kprobes, so the risk for collision is fairly low.

At the point in time that the collisions become a real problem, such
as kgdb starting to use kprobes directly, changing some code for
special re-entrance considerations after using the kernel debugger
might get considered again.  Until then, I will use the simple
approach of checking the mutex and use text_poke() if it is not locked
when the normal kernel execution is stopped on all cores.

The delta to the previous patch is shown below.

Thanks,
Jason.


diff -u b/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
--- b/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -757,6 +757,12 @@ int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 #ifdef CONFIG_DEBUG_RODATA
if (!err)
return err;
+   /* 
+* It is safe to call text_poke() because normal kernel execution
+* is stopped on all cores, so long as the text_mutex is not locked.
+*/
+   if (mutex_is_locked(text_mutex)
+   return -EBUSY;
text_poke((void *)bpt-bpt_addr, arch_kgdb_ops.gdb_bpt_instr,
  BREAK_INSTR_SIZE);
err = probe_kernel_read(opc, (char *)bpt-bpt_addr, BREAK_INSTR_SIZE);
@@ -777,6 +783,12 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
 
if (bpt-type != BP_POKE_BREAKPOINT)
goto knl_write;
+   /* 
+* It is safe to call text_poke() because normal kernel execution
+* is stopped on all cores, so long as the text_mutex is not locked.
+*/
+   if (mutex_is_locked(text_mutex)
+   goto knl_write;
text_poke((void *)bpt-bpt_addr, bpt-saved_instr, BREAK_INSTR_SIZE);
err = probe_kernel_read(opc, (char *)bpt-bpt_addr, BREAK_INSTR_SIZE);
if (err || memcmp(opc, bpt-saved_instr, BREAK_INSTR_SIZE))

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] KGDB error in kernel 2.6.32

[Jason Wessel]

On 03/28/2012 07:01 AM, Rahul Viradiya wrote:
 I am using kernel version 2.6.32.5.. gdbstub.c is not present in path 
 kernel/debug. Is there anything I need to install?
 I have compiled the kernel with kgdb support.
 Applied patch for kdb from 
 ftp://oss.sgi.com/projects/kdb/download/v4.4/kdb-v4.4-2.6.32-x86-2.bz2 and 
 ftp://oss.sgi.com/projects/kdb/download/v4.4/kdb-v4.4-2.6.32-common-2.bz2;


This is actually fixed in the 2.6.32 stable branch, starting at v2.6.32.37

See:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=79760cb772e9b80bac911c78caed52c7921f1bce


Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 0/6] KGDB/KDB/KGDBTS various regression fixes for 2.6.x - 3.4

[Jason Wessel]

This is a set of accumulated regression fixes which will go to to
-stable once reviewed and merged to the mainline.

The break down looks likes this for = kernel x.x

   3.4: Fix an an Smatch warning that appeared in the 3.4 merge window
   3.0: Fix kgdb suite with SMP for all archs without HW single stepping
2.6.36: Fix kgdb sw breakpoints with CONFIG_DEBUG_RODATA=y limitations on x86
2.6.26: Fix oops on kgdb test suite with CONFIG_DEBUG_RODATA
Fix kgdb suite with SMP for all archs with HW single stepping

It is worth mentioning that fixing the kgdb test suite SMP problems
has shown there are some stability problems with SMP ARM kernels and
IPIs.  These problems have been there for as long as ARM has had SMP
support but there was no easy way to trigger the issue that causes a
hard lockup.  At some point I'll take a further look at this, but
anyone is free to run the tests now that they work. :-)

Cheers,
Jason.

---
Jason Wessel (6):
  kdb: Fix smatch warning on dbg_io_ops-is_console
  kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATA
  kgdbts: (1 of 2) fix single step awareness to work correctly with SMP
  kgdbts: (2 of 2) fix single step awareness to work correctly with SMP
  kgdb,debug_core: pass the breakpoint struct instead of address and memory
  x86,kgdb: Fix DEBUG_RODATA limitation using text_poke()

 arch/x86/kernel/kgdb.c|   60 +++
 drivers/misc/kgdbts.c |  177 +
 include/linux/kgdb.h  |7 +-
 kernel/debug/debug_core.c |   53 ++
 kernel/debug/kdb/kdb_io.c |2 +-
 5 files changed, 221 insertions(+), 78 deletions(-)

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 2/6] kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATA

[Jason Wessel]

On x86 the kgdb test suite will oops when the kernel is compiled with
CONFIG_DEBUG_RODATA and you run the tests after boot time. This is
regression has existed since 2.6.26 by commit: b33cb815 (kgdbts: Use
HW breakpoints with CONFIG_DEBUG_RODATA).

The test suite can use hw breakpoints for all the tests, but it has to
execute the hardware breakpoint specific tests first in order to
determine that the hw breakpoints actually work.  Specifically the
very first test causes an oops:

# echo V1I1  /sys/module/kgdbts/parameters/kgdbts
kgdb: Registered I/O driver kgdbts.
kgdbts:RUN plant and detach test

Entering kdb (current=0x880017aa9320, pid 1078) on processor 0 due to 
Keyboard Entry
[0]kdb kgdbts: ERROR PUT: end of test buffer on 'plant_and_detach_test' line 1 
expected OK got $E14#aa
WARNING: at drivers/misc/kgdbts.c:730 run_simple_test+0x151/0x2c0()
[...oops clipped...]

This commit re-orders the running of the tests and puts the RODATA
check into its own function so as to correctly avoid the kernel oops
by detecting and using the hw breakpoints.

Cc: sta...@vger.kernel.org # = 2.6.26
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 drivers/misc/kgdbts.c |   52 ++---
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 3f7ad83..997e94d 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -885,6 +885,22 @@ static void run_singlestep_break_test(void)
kgdbts_break_test();
 }
 
+static void test_debug_rodata(void)
+{
+#ifdef CONFIG_DEBUG_RODATA
+   /* Until there is an api to write to read-only text segments, use
+* HW breakpoints for the remainder of any tests, else print a
+* failure message if hw breakpoints do not work.
+*/
+   if (!(arch_kgdb_ops.flags  KGDB_HW_BREAKPOINT  hwbreaks_ok)) {
+   eprintk(kgdbts: HW breakpoints BROKEN, ending tests\n);
+   return;
+   }
+   force_hwbrks = 1;
+   v1printk(kgdbts:Using HW breakpoints for SW breakpoint tests\n);
+#endif /* CONFIG_DEBUG_RODATA */
+}
+
 static void kgdbts_run_tests(void)
 {
char *ptr;
@@ -907,6 +923,18 @@ static void kgdbts_run_tests(void)
if (ptr)
sstep_test = simple_strtol(ptr+1, NULL, 10);
 
+   /* All HW break point tests */
+   if (arch_kgdb_ops.flags  KGDB_HW_BREAKPOINT) {
+   hwbreaks_ok = 1;
+   v1printk(kgdbts:RUN hw breakpoint test\n);
+   run_breakpoint_test(1);
+   v1printk(kgdbts:RUN hw write breakpoint test\n);
+   run_hw_break_test(1);
+   v1printk(kgdbts:RUN access write breakpoint test\n);
+   run_hw_break_test(0);
+   }
+   test_debug_rodata();
+
/* required internal KGDB tests */
v1printk(kgdbts:RUN plant and detach test\n);
run_plant_and_detach_test(0);
@@ -924,35 +952,11 @@ static void kgdbts_run_tests(void)
 
/* ===Optional tests=== */
 
-   /* All HW break point tests */
-   if (arch_kgdb_ops.flags  KGDB_HW_BREAKPOINT) {
-   hwbreaks_ok = 1;
-   v1printk(kgdbts:RUN hw breakpoint test\n);
-   run_breakpoint_test(1);
-   v1printk(kgdbts:RUN hw write breakpoint test\n);
-   run_hw_break_test(1);
-   v1printk(kgdbts:RUN access write breakpoint test\n);
-   run_hw_break_test(0);
-   }
-
if (nmi_sleep) {
v1printk(kgdbts:RUN NMI sleep %i seconds test\n, nmi_sleep);
run_nmi_sleep_test(nmi_sleep);
}
 
-#ifdef CONFIG_DEBUG_RODATA
-   /* Until there is an api to write to read-only text segments, use
-* HW breakpoints for the remainder of any tests, else print a
-* failure message if hw breakpoints do not work.
-*/
-   if (!(arch_kgdb_ops.flags  KGDB_HW_BREAKPOINT  hwbreaks_ok)) {
-   eprintk(kgdbts: HW breakpoints do not work,
-   skipping remaining tests\n);
-   return;
-   }
-   force_hwbrks = 1;
-#endif /* CONFIG_DEBUG_RODATA */
-
/* If the do_fork test is run it will be the last test that is
 * executed because a kernel thread will be spawned at the very
 * end to unregister the debug hooks.
-- 
1.7.9.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 5/6] kgdb, debug_core: pass the breakpoint struct instead of address and memory

[Jason Wessel]

There is extra state information that needs to be exposed in the
kgdb_bpt structure for tracking how a breakpoint was installed.  The
debug_core only uses the the probe_kernel_write() to install
breakpoints, but this is not enough for all the archs.  Some arch such
as x86 need to use text_poke() in order to install a breakpoint into a
read only page.

Passing the kgdb_bpt structure to kgdb_arch_set_breakpoint() and
kgdb_arch_remove_breakpoint() allows other archs to set the type
variable which indicates how the breakpoint was installed.

Cc: sta...@vger.kernel.org # = 2.6.36
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 include/linux/kgdb.h  |4 ++--
 kernel/debug/debug_core.c |   53 -
 2 files changed, 26 insertions(+), 31 deletions(-)

diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index fa39183..e5d689c 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -207,8 +207,8 @@ extern void kgdb_arch_set_pc(struct pt_regs *regs, unsigned 
long pc);
 
 /* Optional functions. */
 extern int kgdb_validate_break_address(unsigned long addr);
-extern int kgdb_arch_set_breakpoint(unsigned long addr, char *saved_instr);
-extern int kgdb_arch_remove_breakpoint(unsigned long addr, char *bundle);
+extern int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt);
+extern int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt);
 
 /**
  * kgdb_arch_late - Perform any architecture specific initalization.
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 3f88a45..a7e52ca 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -161,37 +161,39 @@ early_param(nokgdbroundup, opt_nokgdbroundup);
  * Weak aliases for breakpoint management,
  * can be overriden by architectures when needed:
  */
-int __weak kgdb_arch_set_breakpoint(unsigned long addr, char *saved_instr)
+int __weak kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 {
int err;
 
-   err = probe_kernel_read(saved_instr, (char *)addr, BREAK_INSTR_SIZE);
+   err = probe_kernel_read(bpt-saved_instr, (char *)bpt-bpt_addr,
+   BREAK_INSTR_SIZE);
if (err)
return err;
-
-   return probe_kernel_write((char *)addr, arch_kgdb_ops.gdb_bpt_instr,
- BREAK_INSTR_SIZE);
+   err = probe_kernel_write((char *)bpt-bpt_addr,
+arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE);
+   return err;
 }
 
-int __weak kgdb_arch_remove_breakpoint(unsigned long addr, char *bundle)
+int __weak kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
 {
-   return probe_kernel_write((char *)addr,
- (char *)bundle, BREAK_INSTR_SIZE);
+   return probe_kernel_write((char *)bpt-bpt_addr,
+ (char *)bpt-saved_instr, BREAK_INSTR_SIZE);
 }
 
 int __weak kgdb_validate_break_address(unsigned long addr)
 {
-   char tmp_variable[BREAK_INSTR_SIZE];
+   struct kgdb_bkpt tmp;
int err;
-   /* Validate setting the breakpoint and then removing it.  In the
+   /* Validate setting the breakpoint and then removing it.  If the
 * remove fails, the kernel needs to emit a bad message because we
 * are deep trouble not being able to put things back the way we
 * found them.
 */
-   err = kgdb_arch_set_breakpoint(addr, tmp_variable);
+   tmp.bpt_addr = addr;
+   err = kgdb_arch_set_breakpoint(tmp);
if (err)
return err;
-   err = kgdb_arch_remove_breakpoint(addr, tmp_variable);
+   err = kgdb_arch_remove_breakpoint(tmp);
if (err)
printk(KERN_ERR KGDB: Critical breakpoint error, kernel 
   memory destroyed at: %lx, addr);
@@ -235,7 +237,6 @@ static void kgdb_flush_swbreak_addr(unsigned long addr)
  */
 int dbg_activate_sw_breakpoints(void)
 {
-   unsigned long addr;
int error;
int ret = 0;
int i;
@@ -244,16 +245,15 @@ int dbg_activate_sw_breakpoints(void)
if (kgdb_break[i].state != BP_SET)
continue;
 
-   addr = kgdb_break[i].bpt_addr;
-   error = kgdb_arch_set_breakpoint(addr,
-   kgdb_break[i].saved_instr);
+   error = kgdb_arch_set_breakpoint(kgdb_break[i]);
if (error) {
ret = error;
-   printk(KERN_INFO KGDB: BP install failed: %lx, addr);
+   printk(KERN_INFO KGDB: BP install failed: %lx,
+  kgdb_break[i].bpt_addr);
continue;
}
 
-   kgdb_flush_swbreak_addr(addr);
+   kgdb_flush_swbreak_addr(kgdb_break[i].bpt_addr);
kgdb_break[i].state = BP_ACTIVE;
}
return ret;
@@ -302,7 +302,6 @@ int dbg_set_sw_break(unsigned long addr)
 
 int

[Kgdb-bugreport] [PATCH 4/6] kgdbts: (2 of 2) fix single step awareness to work correctly with SMP

[Jason Wessel]

The do_fork and sys_open tests have never worked properly on anything
other than a UP configuration with the kgdb test suite.  This is
because the test suite did not fully implement the behavior of a real
debugger.  A real debugger tracks the state of what thread it asked to
single step and can correctly continue other threads of execution or
conditionally stop while waiting for the original thread single step
request to return.

Below is a simple method to cause a fatal kernel oops with the kgdb
test suite on a 2 processor ARM system:

while [ 1 ] ; do ls  /dev/null 2 /dev/null; done
while [ 1 ] ; do ls  /dev/null 2 /dev/null; done
echo V1I1F100  /sys/module/kgdbts/parameters/kgdbts

Very soon after starting the test the kernel will start warning with
messages like:

kgdbts: BP mismatch c002487c expected c0024878
[ cut here ]
WARNING: at drivers/misc/kgdbts.c:317 check_and_rewind_pc+0x9c/0xc4()
[c01f6520] (check_and_rewind_pc+0x9c/0xc4)
[c01f595c] (validate_simple_test+0x3c/0xc4)
[c01f60d4] (run_simple_test+0x1e8/0x274)

The kernel will eventually recovers, but the test suite has completely
failed to test anything useful.

This patch implements behavior similar to a real debugger that does
not rely on hardware single stepping by using only software planted
breakpoints.

In order to mimic a real debugger, the kgdb test suite now tracks the
most recent thread that was continued (cont_thread_id), with the
intent to single step just this thread.  When the response to the
single step request stops in a different thread that hit the original
break point that thread will now get continued, while the debugger
waits for the thread with the single step pending.  Here is a high
level description of the sequence of events.

   cont_instead_of_sstep = 0;

1) set breakpoint at do_fork
2) continue
3)   Save the thread id where we stop to cont_thread_id
4) Remove breakpoint at do_fork
5) Reset the PC if needed depending on kernel exception type
6) soft single step
7)   Check where we stopped
   if current thread != cont_thread_id {
   if (here for more than 2 times for the same thead) {
  ### must be a really busy system, start test again ###
  goto step 1
   }
   goto step 5
   } else {
   cont_instead_of_sstep = 0;
   }
8) clean up and run test again if needed
9) Clear out any threads that were waiting on a break point at the
   point in time the test is ended with get_cont_catch().  This
   happens sometimes because breakpoints are used in place of single
   stepping and some threads could have been in the debugger exception
   handling queue because breakpoints were hit concurrently on
   different CPUs.  This also means we wait at least one second before
   unplumbing the debugger connection at the very end, so as respond
   to any debug threads waiting to be serviced.

Cc: sta...@vger.kernel.org # = 3.0
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 drivers/misc/kgdbts.c |   73 +
 1 file changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 3cad9fc..d087456 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -142,7 +142,9 @@ static int arch_needs_sstep_emulation = 1;
 #else
 static int arch_needs_sstep_emulation;
 #endif
+static unsigned long cont_addr;
 static unsigned long sstep_addr;
+static int restart_from_top_after_write;
 static int sstep_state;
 
 /* Storage for the registers, in GDB format. */
@@ -190,7 +192,8 @@ static int kgdbts_unreg_thread(void *ptr)
 */
while (!final_ack)
msleep_interruptible(1500);
-
+   /* Pause for any other threads to exit after final ack. */
+   msleep_interruptible(1000);
if (configured)
kgdb_unregister_io_module(kgdbts_io_ops);
configured = 0;
@@ -312,13 +315,21 @@ static int check_and_rewind_pc(char *put_str, char *arg)
if (addr + BREAK_INSTR_SIZE == ip)
offset = -BREAK_INSTR_SIZE;
 #endif
-   if (strcmp(arg, silent)  ip + offset != addr) {
+
+   if (arch_needs_sstep_emulation  sstep_addr 
+   ip + offset == sstep_addr 
+   ((!strcmp(arg, sys_open) || !strcmp(arg, do_fork {
+   /* This is special case for emulated single step */
+   v2printk(Emul: rewind hit single step bp\n);
+   restart_from_top_after_write = 1;
+   } else if (strcmp(arg, silent)  ip + offset != addr) {
eprintk(kgdbts: BP mismatch %lx expected %lx\n,
   ip + offset, addr);
return 1;
}
/* Readjust the instruction pointer if needed */
ip += offset;
+   cont_addr = ip;
 #ifdef GDB_ADJUSTS_BREAK_OFFSET
instruction_pointer_set(kgdbts_regs, ip);
 #endif
@@ -328,6 +339,8 @@ static int check_and_rewind_pc(char *put_str, char *arg)
 static int

[Kgdb-bugreport] [PATCH 3/6] kgdbts: (1 of 2) fix single step awareness to work correctly with SMP

[Jason Wessel]

The do_fork and sys_open tests have never worked properly on anything
other than a UP configuration with the kgdb test suite.  This is
because the test suite did not fully implement the behavior of a real
debugger.  A real debugger tracks the state of what thread it asked to
single step and can correctly continue other threads of execution or
conditionally stop while waiting for the original thread single step
request to return.

Below is a simple method to cause a fatal kernel oops with the kgdb
test suite on a 4 processor x86 system:

while [ 1 ] ; do ls  /dev/null 2 /dev/null; done
while [ 1 ] ; do ls  /dev/null 2 /dev/null; done
while [ 1 ] ; do ls  /dev/null 2 /dev/null; done
while [ 1 ] ; do ls  /dev/null 2 /dev/null; done
echo V1I1F1000  /sys/module/kgdbts/parameters/kgdbts

Very soon after starting the test the kernel will oops with a message like:

kgdbts: BP mismatch 3b7da66480 expected 8106a590
WARNING: at drivers/misc/kgdbts.c:303 check_and_rewind_pc+0xe0/0x100()
Call Trace:
 [812994a0] check_and_rewind_pc+0xe0/0x100
 [81298945] validate_simple_test+0x25/0xc0
 [81298f77] run_simple_test+0x107/0x2c0
 [81298a18] kgdbts_put_char+0x18/0x20

The warn will turn to a hard kernel crash shortly after that because
the pc will not get properly rewound to the right value after hitting
a breakpoint leading to a hard lockup.

This change is broken up into 2 pieces because archs that have hw
single stepping (2.6.26 and up) need different changes than archs that
do not have hw single stepping (3.0 and up).  This change implements
the correct behavior for an arch that supports hw single stepping.

A minor defect was fixed where sys_open should be do_sys_open
for the sys_open break point test.  This solves the problem of running
a 64 bit with a 32 bit user space.  The sys_open() never gets called
when using the 32 bit file system for the kgdb testsuite because the
32 bit binaries invoke the compat_sys_open() call leading to the test
never completing.

In order to mimic a real debugger, the kgdb test suite now tracks the
most recent thread that was continued (cont_thread_id), with the
intent to single step just this thread.  When the response to the
single step request stops in a different thread that hit the original
break point that thread will now get continued, while the debugger
waits for the thread with the single step pending.  Here is a high
level description of the sequence of events.

   cont_instead_of_sstep = 0;

1) set breakpoint at do_fork
2) continue
3)   Save the thread id where we stop to cont_thread_id
4) Remove breakpoint at do_fork
5) Reset the PC if needed depending on kernel exception type
6) if (cont_instead_of_sstep) { continue } else { single step }
7)   Check where we stopped
   if current thread != cont_thread_id {
   cont_instead_of_sstep = 1;
   goto step 5
   } else {
   cont_instead_of_sstep = 0;
   }
8) clean up and run test again if needed

Cc: sta...@vger.kernel.org # = 2.6.26
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 drivers/misc/kgdbts.c |   54 +++--
 1 file changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 997e94d..3cad9fc 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -134,6 +134,9 @@ static int force_hwbrks;
 static int hwbreaks_ok;
 static int hw_break_val;
 static int hw_break_val2;
+static int cont_instead_of_sstep;
+static unsigned long cont_thread_id;
+static unsigned long sstep_thread_id;
 #if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || defined(CONFIG_SPARC)
 static int arch_needs_sstep_emulation = 1;
 #else
@@ -211,7 +214,7 @@ static unsigned long lookup_addr(char *arg)
if (!strcmp(arg, kgdbts_break_test))
addr = (unsigned long)kgdbts_break_test;
else if (!strcmp(arg, sys_open))
-   addr = (unsigned long)sys_open;
+   addr = (unsigned long)do_sys_open;
else if (!strcmp(arg, do_fork))
addr = (unsigned long)do_fork;
else if (!strcmp(arg, hw_break_val))
@@ -283,6 +286,16 @@ static void hw_break_val_write(void)
hw_break_val++;
 }
 
+static int get_thread_id_continue(char *put_str, char *arg)
+{
+   char *ptr = put_str[11];
+
+   if (put_str[1] != 'T' || put_str[2] != '0')
+   return 1;
+   kgdb_hex2long(ptr, cont_thread_id);
+   return 0;
+}
+
 static int check_and_rewind_pc(char *put_str, char *arg)
 {
unsigned long addr = lookup_addr(arg);
@@ -324,6 +337,18 @@ static int check_single_step(char *put_str, char *arg)
gdb_regs_to_pt_regs(kgdbts_gdb_regs, kgdbts_regs);
v2printk(Singlestep stopped at IP: %lx\n,
   instruction_pointer(kgdbts_regs));
+
+   if (sstep_thread_id != cont_thread_id  !arch_needs_sstep_emulation) {
+   /*
+* Ensure we stopped in the same

[Kgdb-bugreport] [PATCH 1/6] kdb: Fix smatch warning on dbg_io_ops-is_console

[Jason Wessel]

The Smatch tool warned that the change from commit b8adde8dd
(kdb: Avoid using dbg_io_ops until it is initialized) should
add another null check later in the kdb_printf().

It is worth noting that the second use of dbg_io_ops-is_console
is protected by the KDB_PAGER state variable which would only
get set when kdb is fully active and initialized.  If we
ever encounter changes or defects in the KDB_PAGER state
we do not want to crash the kernel in a kdb_printf/printk.

CC: Tim Bird tim.b...@am.sony.com
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/kdb/kdb_io.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 9b5f17d..bb9520f 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -743,7 +743,7 @@ kdb_printit:
kdb_input_flush();
c = console_drivers;
 
-   if (!dbg_io_ops-is_console) {
+   if (dbg_io_ops  !dbg_io_ops-is_console) {
len = strlen(moreprompt);
cp = moreprompt;
while (len--) {
-- 
1.7.9.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 6/6] x86, kgdb: Fix DEBUG_RODATA limitation using text_poke()

[Jason Wessel]

There has long been a limitation using software breakpoints with a
kernel compiled with CONFIG_DEBUG_RODATA going back to 2.6.26. For
this particular patch, it will apply cleanly and has been tested all
the way back to 2.6.36.

The kprobes code uses the text_poke() function which accommodates
writing a breakpoint into a read-only page.  The x86 kgdb code can
solve the problem similarly by overriding the default breakpoint
set/remove routines and using text_poke() directly.

The x86 kgdb code will first attempt to use the traditional
probe_kernel_write(), and next try using a the text_poke() function.
The break point install method is tracked such that the correct break
point removal routine will get called later on.

Cc: x...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: sta...@vger.kernel.org # = 2.6.36
Inspried-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 arch/x86/kernel/kgdb.c |   60 
 include/linux/kgdb.h   |3 ++-
 2 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index fdc37b3..b9bd9d8 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -43,6 +43,8 @@
 #include linux/smp.h
 #include linux/nmi.h
 #include linux/hw_breakpoint.h
+#include linux/uaccess.h
+#include linux/memory.h
 
 #include asm/debugreg.h
 #include asm/apicdef.h
@@ -742,6 +744,64 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long 
ip)
regs-ip = ip;
 }
 
+int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
+{
+   int err;
+   char opc[BREAK_INSTR_SIZE];
+
+   bpt-type = BP_BREAKPOINT;
+   err = probe_kernel_read(bpt-saved_instr, (char *)bpt-bpt_addr,
+   BREAK_INSTR_SIZE);
+   if (err)
+   return err;
+   err = probe_kernel_write((char *)bpt-bpt_addr,
+arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE);
+#ifdef CONFIG_DEBUG_RODATA
+   if (!err)
+   return err;
+   /*
+* It is safe to call text_poke() because normal kernel execution
+* is stopped on all cores, so long as the text_mutex is not locked.
+*/
+   if (mutex_is_locked(text_mutex))
+   return -EBUSY;
+   text_poke((void *)bpt-bpt_addr, arch_kgdb_ops.gdb_bpt_instr,
+ BREAK_INSTR_SIZE);
+   err = probe_kernel_read(opc, (char *)bpt-bpt_addr, BREAK_INSTR_SIZE);
+   if (err)
+   return err;
+   if (memcmp(opc, arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE))
+   return -EINVAL;
+   bpt-type = BP_POKE_BREAKPOINT;
+#endif /* CONFIG_DEBUG_RODATA */
+   return err;
+}
+
+int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
+{
+#ifdef CONFIG_DEBUG_RODATA
+   int err;
+   char opc[BREAK_INSTR_SIZE];
+
+   if (bpt-type != BP_POKE_BREAKPOINT)
+   goto knl_write;
+   /*
+* It is safe to call text_poke() because normal kernel execution
+* is stopped on all cores, so long as the text_mutex is not locked.
+*/
+   if (mutex_is_locked(text_mutex))
+   goto knl_write;
+   text_poke((void *)bpt-bpt_addr, bpt-saved_instr, BREAK_INSTR_SIZE);
+   err = probe_kernel_read(opc, (char *)bpt-bpt_addr, BREAK_INSTR_SIZE);
+   if (err || memcmp(opc, bpt-saved_instr, BREAK_INSTR_SIZE))
+   goto knl_write;
+   return err;
+knl_write:
+#endif /* CONFIG_DEBUG_RODATA */
+   return probe_kernel_write((char *)bpt-bpt_addr,
+ (char *)bpt-saved_instr, BREAK_INSTR_SIZE);
+}
+
 struct kgdb_arch arch_kgdb_ops = {
/* Breakpoint instruction: */
.gdb_bpt_instr  = { 0xcc },
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index e5d689c..c4d2fc1 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -63,7 +63,8 @@ enum kgdb_bptype {
BP_HARDWARE_BREAKPOINT,
BP_WRITE_WATCHPOINT,
BP_READ_WATCHPOINT,
-   BP_ACCESS_WATCHPOINT
+   BP_ACCESS_WATCHPOINT,
+   BP_POKE_BREAKPOINT,
 };
 
 enum kgdb_bpstate {
-- 
1.7.9.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] Kgdb Gdb on a serial link

[Jason Wessel]

On 03/28/2012 02:01 AM, Gilles Allard wrote:
 On Wednesday 22 February 2012 10:32:43 Gilles Allard wrote:
  To debug a driver, I try to use Kgdb along with Gdb on a serial link
 between an host machine and the target one running the buggy driver.

 - Up to now, everything seems to be as expected. But if I try to continue
 target boot process using monitor go, here is what I got ( and here is
 the problem ) :

 (gdb) monitor go
 go must execute on the entry cpu, please use cpu -1 and then execute go
 (gdb)

 From that point, I cannot do anything else but manually reset the target
 and
 kill the Gdb session because of what seems to be an error message.
 So : is this a real bug or is there something wrong in the procedure I use
 ?
 Hello to all of you.

 Does any one can help ?
 I really need help for that problem; I really don't now what to do !
 I'll be grateful  for any information ( suggestion, hint ... ).

You cannot use monitor commands for run control.  If you are using gdb, you 
need to use the continue command and the gdb specific run control commands.

I had intentionally disabled some features from the monitor pass through 
because they are not safe to use from the gdb context.

Jason.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [GIT PULL] KGDB/KDB regression fixes for 3.4-rc2

[Jason Wessel]

The following changes since commit 1ba0c1720eb0de2d0f3abf84c0b128d10af520d1:

  kdb: Add message about CONFIG_DEBUG_RODATA on failure to install breakpoint 
(2012-03-22 15:07:16 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linus-3.4-rc2

for you to fetch changes up to 3751d3e85cf693e10e2c47c03c8caa65e171099b:

  x86,kgdb: Fix DEBUG_RODATA limitation using text_poke() (2012-03-29 17:41:25 
-0500)


KGDB/KDB regression fixes
   3.4: Fix an an Smatch warning that appeared in the 3.4 merge window
   3.0: Fix kgdb test suite with SMP for all archs without HW single stepping
2.6.36: Fix kgdb sw breakpoints with CONFIG_DEBUG_RODATA=y limitations on x86
2.6.26: Fix oops on kgdb test suite with CONFIG_DEBUG_RODATA
Fix kgdb test suite with SMP for all archs with HW single stepping


Jason Wessel (6):
  kdb: Fix smatch warning on dbg_io_ops-is_console
  kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATA
  kgdbts: (1 of 2) fix single step awareness to work correctly with SMP
  kgdbts: (2 of 2) fix single step awareness to work correctly with SMP
  kgdb,debug_core: pass the breakpoint struct instead of address and memory
  x86,kgdb: Fix DEBUG_RODATA limitation using text_poke()

 arch/x86/kernel/kgdb.c|   60 +
 drivers/misc/kgdbts.c |  160 -
 include/linux/kgdb.h  |7 +-
 kernel/debug/debug_core.c |   53 +++
 kernel/debug/kdb/kdb_io.c |2 +-
 5 files changed, 204 insertions(+), 78 deletions(-)

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] Trouble setting software breakpoints

[Jason Wessel]

On 04/07/2012 12:11 PM, Ward, David - 0663 - MITLL wrote:
 Nevermind -- I added the commits tagged 'for_linus-3.4-rc2' onto my 
 kernel and I can set software breakpoints now.

Glad to see it is working for you now.

I had already sent the patch series to the -stable/-longterm trees, and they 
are queued for future releases.

Cheers,
Jason.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 1/3] kdb: Remove unused KDB_FLAG_ONLY_DO_DUMP

[Jason Wessel]

This code cleanup was missed in the original kdb merge, and this code
is simply not used at all.  The code that was previously used to set
the KDB_FLAG_ONLY_DO_DUMP was removed prior to the initial kdb merge.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 include/linux/kdb.h |2 --
 kernel/debug/kdb/kdb_main.c |   15 +--
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/include/linux/kdb.h b/include/linux/kdb.h
index 0647258..42d9e86 100644
--- a/include/linux/kdb.h
+++ b/include/linux/kdb.h
@@ -75,8 +75,6 @@ extern const char *kdb_diemsg;
 #define KDB_FLAG_CATASTROPHIC  (1  1) /* A catastrophic event has occurred */
 #define KDB_FLAG_CMD_INTERRUPT (1  2) /* Previous command was interrupted */
 #define KDB_FLAG_NOIPI (1  3) /* Do not send IPIs */
-#define KDB_FLAG_ONLY_DO_DUMP  (1  4) /* Only do a dump, used when
- * kdb is off */
 #define KDB_FLAG_NO_CONSOLE(1  5) /* No console is available,
  * kdb is disabled */
 #define KDB_FLAG_NO_VT_CONSOLE (1  6) /* No VT console is available, do
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 1f91413..31df170 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -139,11 +139,10 @@ static const int __nkdb_err = sizeof(kdbmsgs) / 
sizeof(kdbmsg_t);
 static char *__env[] = {
 #if defined(CONFIG_SMP)
  PROMPT=[%d]kdb ,
- MOREPROMPT=[%d]more ,
 #else
  PROMPT=kdb ,
- MOREPROMPT=more ,
 #endif
+ MOREPROMPT=more ,
  RADIX=16,
  MDCOUNT=8,  /* lines of md output */
  KDB_PLATFORM_ENV,
@@ -1236,18 +1235,6 @@ static int kdb_local(kdb_reason_t reason, int error, 
struct pt_regs *regs,
*cmdbuf = '\0';
*(cmd_hist[cmd_head]) = '\0';
 
-   if (KDB_FLAG(ONLY_DO_DUMP)) {
-   /* kdb is off but a catastrophic error requires a dump.
-* Take the dump and reboot.
-* Turn on logging so the kdb output appears in the log
-* buffer in the dump.
-*/
-   const char *setargs[] = { set, LOGGING, 1 };
-   kdb_set(2, setargs);
-   kdb_reboot(0, NULL);
-   /*NOTREACHED*/
-   }
-
 do_full_getstr:
 #if defined(CONFIG_SMP)
snprintf(kdb_prompt_str, CMD_BUFLEN, kdbgetenv(PROMPT),
-- 
1.7.9.5


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 0/3] patches for the 3.5 merge window.

[Jason Wessel]

This is just a simple series for the 3.5 merge window, and I'll
send the pull request after the next linux-next cycle
unless anyone pipes up.

Cheers,
Jason.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 3/3] kernel/debug: Make use of KGDB_REASON_NMI

[Jason Wessel]

From: Anton Vorontsov anton.voront...@linaro.org

Currently kernel never set KGDB_REASON_NMI. We do now, when we enter
KGDB/KDB from an NMI.

This is not to be confused with kgdb_nmicallback(), NMI callback is
an entry for the slave CPUs during CPUs roundup, but REASON_NMI is the
entry for the master CPU.

Signed-off-by: Anton Vorontsov anton.voront...@linaro.org
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/kdb/kdb_debugger.c |4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/debug/kdb/kdb_debugger.c b/kernel/debug/kdb/kdb_debugger.c
index 8b68ce7..be7b33b 100644
--- a/kernel/debug/kdb/kdb_debugger.c
+++ b/kernel/debug/kdb/kdb_debugger.c
@@ -12,6 +12,7 @@
 #include linux/kdb.h
 #include linux/kdebug.h
 #include linux/export.h
+#include linux/hardirq.h
 #include kdb_private.h
 #include ../debug_core.h
 
@@ -52,6 +53,9 @@ int kdb_stub(struct kgdb_state *ks)
if (atomic_read(kgdb_setting_breakpoint))
reason = KDB_REASON_KEYBOARD;
 
+   if (in_nmi())
+   reason = KDB_REASON_NMI;
+
for (i = 0, bp = kdb_breakpoints; i  KDB_MAXBPT; i++, bp++) {
if ((bp-bp_enabled)  (bp-bp_addr == addr)) {
reason = KDB_REASON_BREAK;
-- 
1.7.9.5


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 2/3] kdb: Remove cpu from the more prompt

[Jason Wessel]

Having the CPU in the more prompt is completely redundent vs the
standard kdb prompt, and it also wastes 32 bytes on the stack.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 kernel/debug/kdb/kdb_io.c |   11 ---
 1 file changed, 11 deletions(-)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index bb9520f..0a69d2a 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -715,9 +715,6 @@ kdb_printit:
/* check for having reached the LINES number of printed lines */
if (kdb_nextline == linecount) {
char buf1[16] = ;
-#if defined(CONFIG_SMP)
-   char buf2[32];
-#endif
 
/* Watch out for recursion here.  Any routine that calls
 * kdb_printf will come back through here.  And kdb_read
@@ -732,14 +729,6 @@ kdb_printit:
if (moreprompt == NULL)
moreprompt = more ;
 
-#if defined(CONFIG_SMP)
-   if (strchr(moreprompt, '%')) {
-   sprintf(buf2, moreprompt, get_cpu());
-   put_cpu();
-   moreprompt = buf2;
-   }
-#endif
-
kdb_input_flush();
c = console_drivers;
 
-- 
1.7.9.5


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 01/11] kernel/debug: Make use of KGDB_REASON_NMI

[Jason Wessel]

On 07/30/2012 06:58 AM, Anton Vorontsov wrote:
 Currently kernel never set KGDB_REASON_NMI. We do now, when we enter
 KGDB/KDB from an NMI.

 This is not to be confused with kgdb_nmicallback(), NMI callback is
 an entry for the slave CPUs during CPUs roundup, but REASON_NMI is the
 entry for the master CPU.

No need for confusion here :-)

I'll take this one for the kernel merge window if it passes regression tests, 
no reason not to be setting the stop codes properly.

Thanks,
Jason.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [GIT PULL] KGDB/KDB/dbgp fixes for 3.6-rc1

[Jason Wessel]

This was ready to go in time for the 3.6 merge window, but the pull
request had not been sent prior to the merge window closing, as it was
waiting on some final regression testing which has since passed
correctly.

There are no new features, those will be delayed to the 3.7
window. There are only fixes/cleanup against the usual kernel churn
and at least we are removing more lines than we add. :-)

Thanks,
Jason.


The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:

  Linux 3.5 (2012-07-21 13:58:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linux-3.6-rc1

for you to fetch changes up to f96a4216e85050c0a9d41a41ecb0ae9d8e39b509:

  USB: echi-dbgp: increase the controller wait time to come out of halt. 
(2012-07-31 08:16:43 -0500)


KGDB/KDB/usb-dbgp fixes and cleanups
   usb-dbgp - increase the controller wait time to come out of halt.
   kdb - Remove unused KDB_FLAG_ONLY_DO_DUMP code and cpu in more prompt
   debug core - pass NMI type on archs that provide NMI types


Anton Vorontsov (1):
  kernel/debug: Make use of KGDB_REASON_NMI

Colin Ian King (1):
  USB: echi-dbgp: increase the controller wait time to come out of halt.

Jason Wessel (2):
  kdb: Remove unused KDB_FLAG_ONLY_DO_DUMP
  kdb: Remove cpu from the more prompt

 drivers/usb/early/ehci-dbgp.c   |2 +-
 include/linux/kdb.h |2 --
 kernel/debug/kdb/kdb_debugger.c |4 
 kernel/debug/kdb/kdb_io.c   |   11 ---
 kernel/debug/kdb/kdb_main.c |   15 +--
 5 files changed, 6 insertions(+), 28 deletions(-)

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 4/4] kgdboc: Accept either kbd or kdb to activate the vga + keyboard kdb shell

[Jason Wessel]

It is a common enough mistake for people to specify kdb when they
meant to type kbd that the kgdboc can just accept both since they
both mean the same thing anyway.  Specifically it is for the case
where you want kdb to be active on your graphics console + keyboard
(where kbd was the original abbreviation for keyboard).

With this change kgdboc will now accept either to mean the same thing:
   kgdboc=kbd
   kgdboc=kdb

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 drivers/tty/serial/kgdboc.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
index 2b42a01..509e714 100644
--- a/drivers/tty/serial/kgdboc.c
+++ b/drivers/tty/serial/kgdboc.c
@@ -97,7 +97,8 @@ static void kgdboc_restore_input(void)
 
 static int kgdboc_register_kbd(char **cptr)
 {
-   if (strncmp(*cptr, kbd, 3) == 0) {
+   if (strncmp(*cptr, kbd, 3) == 0 ||
+   strncmp(*cptr, kdb, 3) == 0) {
if (kdb_poll_idx  KDB_POLL_FUNC_MAX) {
kdb_poll_funcs[kdb_poll_idx] = kdb_get_kbd_char;
kdb_poll_idx++;
-- 
1.7.9.5


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 2/4] pmac_zilog, kdb: Fix console poll hook to return instead of loop

[Jason Wessel]

kdb - kgdb transitioning does not work properly with this UART
driver because the get character routine loops indefinitely as opposed
to returning NO_POLL_CHAR per the expectation of the KDB I/O driver
API.

The symptom is a kernel hang when trying to switch debug modes.

Cc: Alan Cox a...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 drivers/tty/serial/pmac_zilog.c |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
index 654755a..333c8d0 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -1348,10 +1348,16 @@ static int pmz_verify_port(struct uart_port *port, 
struct serial_struct *ser)
 static int pmz_poll_get_char(struct uart_port *port)
 {
struct uart_pmac_port *uap = (struct uart_pmac_port *)port;
+   int tries = 2;
 
-   while ((read_zsreg(uap, R0)  Rx_CH_AV) == 0)
-   udelay(5);
-   return read_zsdata(uap);
+   while (tries) {
+   if ((read_zsreg(uap, R0)  Rx_CH_AV) != 0)
+   return read_zsdata(uap);
+   if (tries--)
+   udelay(5);
+   }
+
+   return NO_POLL_CHAR;
 }
 
 static void pmz_poll_put_char(struct uart_port *port, unsigned char c)
-- 
1.7.9.5


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 1/4] mips, kgdb: fix recursive page fault with CONFIG_KPROBES

[Jason Wessel]

This fault was detected using the kgdb test suite on boot and it
crashes recursively due to the fact that CONFIG_KPROBES on mips adds
an extra die notifier in the page fault handler.  The crash signature
looks like this:

kgdbts:RUN bad memory access test
KGDB: re-enter exception: ALL breakpoints killed
Call Trace:
[807b7548] dump_stack+0x20/0x54
[807b7548] dump_stack+0x20/0x54

The fix for now is to have kgdb return immediately if the fault type
is DIE_PAGE_FAULT and allow the kprobe code to decide what is supposed
to happen.

Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 arch/mips/kernel/kgdb.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index f4546e9..23817a6 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -283,6 +283,15 @@ static int kgdb_mips_notify(struct notifier_block *self, 
unsigned long cmd,
struct pt_regs *regs = args-regs;
int trap = (regs-cp0_cause  0x7c)  2;
 
+#ifdef CONFIG_KPROBES
+   /*
+* Return immediately if the kprobes fault notifier has set
+* DIE_PAGE_FAULT.
+*/
+   if (cmd == DIE_PAGE_FAULT)
+   return NOTIFY_DONE;
+#endif /* CONFIG_KPROBES */
+
/* Userspace events, ignore. */
if (user_mode(regs))
return NOTIFY_DONE;
-- 
1.7.9.5


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 02/11] kdb: Implement disable_nmi command

[Jason Wessel]

On 09/13/2012 10:03 AM, Anton Vorontsov wrote:
 This command disables NMI-entry. If NMI source has been previously shared
 with a serial console (debug port), this effectively releases the port
 from KDB exclusive use, and makes the console available for normal use.
 
 Of course, NMI can be reenabled, enable_nmi modparam is used for that:
 
   echo 1  /sys/module/kdb/parameters/enable_nmi
 
 Signed-off-by: Anton Vorontsov anton.voront...@linaro.org
 ---
  kernel/debug/kdb/kdb_main.c | 29 +
  1 file changed, 29 insertions(+)
 
 diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
 index 31df170..9fadff1 100644
 --- a/kernel/debug/kdb/kdb_main.c
 +++ b/kernel/debug/kdb/kdb_main.c
 @@ -21,6 +21,7 @@
  #include linux/smp.h
  #include linux/utsname.h
  #include linux/vmalloc.h
 +#include linux/atomic.h
  #include linux/module.h
  #include linux/mm.h
  #include linux/init.h
 @@ -2107,6 +2108,32 @@ static int kdb_dmesg(int argc, const char **argv)
   return 0;
  }
  #endif /* CONFIG_PRINTK */
 +
 +/* Make sure we balance enable/disable calls, must disable first. */
 +static atomic_t kdb_nmi_disabled;
 +
 +static int kdb_disable_nmi(int argc, const char *argv[])
 +{
 + if (atomic_read(kdb_nmi_disabled))
 + return 0;
 + atomic_set(kdb_nmi_disabled, 1);
 + kgdb_enable_nmi(0);
 + return 0;
 +}
 +
 +static int kdb_param_enable_nmi(const char *val, const struct kernel_param 
 *kp)
 +{
 + if (!atomic_add_unless(kdb_nmi_disabled, -1, 0))
 + return -EINVAL;
 + kgdb_enable_nmi(1);
 + return 0;
 +}
 +
 +static const struct kernel_param_ops kdb_param_ops_enable_nmi = {
 + .set = kdb_param_enable_nmi,
 +};
 +module_param_cb(enable_nmi, kdb_param_ops_enable_nmi, NULL, 0600);
 +
  /*
   * kdb_cpu - This function implements the 'cpu' command.
   *   cpu [cpunum]
 @@ -2851,6 +2878,8 @@ static void __init kdb_inittab(void)
   kdb_register_repeat(dmesg, kdb_dmesg, [lines],
 Display syslog buffer, 0, KDB_REPEAT_NONE);
  #endif


Based on what I commented in the 01/11 patch, we don't want to register a 
command if the architecture doesn't actually have it, because it just leads to 
confusion.

It needs to have an if

if (arch_kgdb_ops-enable_nmi) {


 + kdb_register_repeat(disable_nmi, kdb_disable_nmi, ,
 +   Disable NMI entry to KDB, 0, KDB_REPEAT_NONE);

}

   kdb_register_repeat(defcmd, kdb_defcmd, name \usage\ \help\,
 Define a set of commands, down to endefcmd, 0, KDB_REPEAT_NONE);
   kdb_register_repeat(kill, kdb_kill, -signal pid,
 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 07/11] tty/serial: Add kgdb_nmi driver

[Jason Wessel]

On 09/13/2012 10:03 AM, Anton Vorontsov wrote:
 This special driver makes it possible to temporary use NMI debugger port
 as a normal console by issuing 'nmi_console' command (assuming that the
 port is attached to KGDB).
 
 Unlike KDB's disable_nmi command, with this driver you are always able
 to go back to the debugger using KGDB escape sequence ($3#33).  This is
 because this console driver processes the input in NMI context, and thus
 is able to intercept the magic sequence.
 
 Note that since the console interprets input and uses polling
 communication methods, for things like PPP it is still better to fully
 detach debugger port from the KGDB NMI (i.e. disable_nmi), and use raw
 console.
 
 Usually, to enter the debugger one have to type the magic sequence, so
 initially the kernel will print the following prompt on the NMI debugger
 console:
 
   Type $3#33 to enter the debugger
 
 For convenience, there is a kgdb_fiq.knock kernel command line option,
 when set to 0, this turns the special command to just a return key
 press, so the kernel will be printing this:
 
   Hit return to enter the debugger
 
 This is more convenient for long debugging sessions, although it makes
 nmi_console feature somewhat useless.
 
 And for the cases when NMI connected to a dedicated button, the knocking
 can be disabled altogether by setting kgdb_fiq.knock to -1.
 
 Suggested-by: Colin Cross ccr...@android.com
 Signed-off-by: Anton Vorontsov anton.voront...@linaro.org
 ---
  drivers/tty/serial/Kconfig|  19 ++
  drivers/tty/serial/Makefile   |   1 +
  drivers/tty/serial/kgdb_nmi.c | 396 
 ++
  drivers/tty/serial/kgdboc.c   |   6 +
  include/linux/kgdb.h  |  10 ++
  5 files changed, 432 insertions(+)
  create mode 100644 drivers/tty/serial/kgdb_nmi.c
 
 diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
 index 26907cf..b22e45b 100644
 --- a/drivers/tty/serial/Kconfig
 +++ b/drivers/tty/serial/Kconfig
 @@ -141,6 +141,25 @@ config SERIAL_ATMEL_TTYAT
  
 Say Y if you have an external 8250/16C550 UART.  If unsure, say N.
  
 +config SERIAL_KGDB_NMI
 + bool Serial console over KGDB NMI debugger port
 + depends on KGDB_SERIAL_CONSOLE
 + help
 +   This special driver allows you to temporary use NMI debugger port
 +   as a normal console (assuming that the port is attached to KGDB).
 +
 +   Unlike KDB's disable_nmi command, with this driver you are always
 +   able to go back to the debugger using KGDB escape sequence ($3#33).
 +   This is because this console driver processes the input in NMI
 +   context, and thus is able to intercept the magic sequence.
 +
 +   Note that since the console interprets input and uses polling
 +   communication methods, for things like PPP you still must fully
 +   detach debugger port from the KGDB NMI (i.e. disable_nmi), and
 +   use raw console.
 +
 +   If unsure, say N.
 +
  config SERIAL_KS8695
   bool Micrel KS8695 (Centaur) serial port support
   depends on ARCH_KS8695
 diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
 index ce88667..4f694da 100644
 --- a/drivers/tty/serial/Makefile
 +++ b/drivers/tty/serial/Makefile
 @@ -61,6 +61,7 @@ obj-$(CONFIG_SERIAL_MSM_HS) += msm_serial_hs.o
  obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
  obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
  obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
 +obj-$(CONFIG_SERIAL_KGDB_NMI) += kgdb_nmi.o
  obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
  obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
  obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
 diff --git a/drivers/tty/serial/kgdb_nmi.c b/drivers/tty/serial/kgdb_nmi.c
 new file mode 100644
 index 000..57bf744
 --- /dev/null
 +++ b/drivers/tty/serial/kgdb_nmi.c
 @@ -0,0 +1,396 @@
 +/*
 + * KGDB NMI serial console
 + *
 + * Copyright 2010 Google, Inc.
 + * Arve Hjønnevåg a...@android.com
 + * Colin Cross ccr...@android.com
 + * Copyright 2012 Linaro Ltd.
 + * Anton Vorontsov anton.voront...@linaro.org
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License version 2 as published
 + * by the Free Software Foundation.
 + */
 +
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/compiler.h
 +#include linux/init.h
 +#include linux/slab.h
 +#include linux/errno.h
 +#include linux/atomic.h
 +#include linux/console.h
 +#include linux/tty.h
 +#include linux/tty_driver.h
 +#include linux/tty_flip.h
 +#include linux/interrupt.h
 +#include linux/hrtimer.h
 +#include linux/tick.h
 +#include linux/kfifo.h
 +#include linux/kgdb.h
 +#include linux/kdb.h
 +
 +static int kgdb_nmi_knock = 1;
 +module_param_named(knock, kgdb_nmi_knock, int, 0600);
 +MODULE_PARM_DESC(knock, if set to 1 (default), the special '$3#33' command 
 + must be used to enter the 

Re: [Kgdb-bugreport] [PATCH] kdb: Remove unhandled ssb command

[Jason Wessel]

On 02/12/2013 04:34 AM, Vincent wrote:
 The 'ssb' command can only be handled when we have a disassembler, to check 
 for
 branches, so remove the 'ssb' command for now.

Wow, that was fast.  This looks fine too.

I'll add it to the merge queue.

Thanks!
Jason.


 Signed-off-by: Vincent Stehlé vincent.ste...@laposte.net
 Cc: jason.wes...@windriver.com
 Cc: kgdb-bugreport@lists.sourceforge.net
 ---

 Hi,

 Here is a patch proposal to remove 'ssb' from the kernel, which works for 
 me.

 For simplicity, following defines like KDB_CMD_KGDB or debug traces numbers
 have not been touched. Please let me know if they should be renumbered.

 Best regards,

 V.

  kernel/debug/kdb/kdb_bp.c   |   20 ++--
  kernel/debug/kdb/kdb_debugger.c |1 -
  kernel/debug/kdb/kdb_main.c |   16 
  kernel/debug/kdb/kdb_private.h  |4 
  4 files changed, 2 insertions(+), 39 deletions(-)

 diff --git a/kernel/debug/kdb/kdb_bp.c b/kernel/debug/kdb/kdb_bp.c
 index 8418c2f..70a5046 100644
 --- a/kernel/debug/kdb/kdb_bp.c
 +++ b/kernel/debug/kdb/kdb_bp.c
 @@ -486,11 +486,9 @@ static int kdb_bc(int argc, const char **argv)
  /*
   * kdb_ss
   *
 - *   Process the 'ss' (Single Step) and 'ssb' (Single Step to Branch)
 - *   commands.
 + *   Process the 'ss' (Single Step) command.
   *
   *   ss
 - *   ssb
   *
   * Parameters:
   *   argcArgument count
 @@ -498,35 +496,23 @@ static int kdb_bc(int argc, const char **argv)
   * Outputs:
   *   None.
   * Returns:
 - *   KDB_CMD_SS[B] for success, a kdb error if failure.
 + *   KDB_CMD_SS for success, a kdb error if failure.
   * Locking:
   *   None.
   * Remarks:
   *
   *   Set the arch specific option to trigger a debug trap after the next
   *   instruction.
 - *
 - *   For 'ssb', set the trace flag in the debug trap handler
 - *   after printing the current insn and return directly without
 - *   invoking the kdb command processor, until a branch instruction
 - *   is encountered.
   */
  
  static int kdb_ss(int argc, const char **argv)
  {
 - int ssb = 0;
 -
 - ssb = (strcmp(argv[0], ssb) == 0);
   if (argc != 0)
   return KDB_ARGCOUNT;
   /*
* Set trace flag and go.
*/
   KDB_STATE_SET(DOING_SS);
 - if (ssb) {
 - KDB_STATE_SET(DOING_SSB);
 - return KDB_CMD_SSB;
 - }
   return KDB_CMD_SS;
  }
  
 @@ -561,8 +547,6 @@ void __init kdb_initbptab(void)
  
   kdb_register_repeat(ss, kdb_ss, ,
   Single Step, 1, KDB_REPEAT_NO_ARGS);
 - kdb_register_repeat(ssb, kdb_ss, ,
 - Single step to branch/call, 0, KDB_REPEAT_NO_ARGS);
   /*
* Architecture dependent initialization.
*/
 diff --git a/kernel/debug/kdb/kdb_debugger.c b/kernel/debug/kdb/kdb_debugger.c
 index be7b33b..2ab4f1a 100644
 --- a/kernel/debug/kdb/kdb_debugger.c
 +++ b/kernel/debug/kdb/kdb_debugger.c
 @@ -100,7 +100,6 @@ int kdb_stub(struct kgdb_state *ks)
   /* Remove any breakpoints as needed by kdb and clear single step */
   kdb_bp_remove();
   KDB_STATE_CLEAR(DOING_SS);
 - KDB_STATE_CLEAR(DOING_SSB);
   KDB_STATE_SET(PAGER);
   /* zero out any offline cpu data */
   for_each_present_cpu(i) {
 diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
 index 8875254..c37ab68 100644
 --- a/kernel/debug/kdb/kdb_main.c
 +++ b/kernel/debug/kdb/kdb_main.c
 @@ -1112,7 +1112,6 @@ void kdb_set_current_task(struct task_struct *p)
   *   KDB_CMD_GO  User typed 'go'.
   *   KDB_CMD_CPU User switched to another cpu.
   *   KDB_CMD_SS  Single step.
 - *   KDB_CMD_SSB Single step until branch.
   */
  static int kdb_local(kdb_reason_t reason, int error, struct pt_regs *regs,
kdb_dbtrap_t db_result)
 @@ -1151,14 +1150,6 @@ static int kdb_local(kdb_reason_t reason, int error, 
 struct pt_regs *regs,
   kdb_printf(due to Debug @  kdb_machreg_fmt \n,
  instruction_pointer(regs));
   break;
 - case KDB_DB_SSB:
 - /*
 -  * In the midst of ssb command. Just return.
 -  */
 - KDB_DEBUG_STATE(kdb_local 3, reason);
 - return KDB_CMD_SSB; /* Continue with SSB command */
 -
 - break;
   case KDB_DB_SS:
   break;
   case KDB_DB_SSBPT:
 @@ -1281,7 +1272,6 @@ do_full_getstr:
   if (diag == KDB_CMD_GO
|| diag == KDB_CMD_CPU
|| diag == KDB_CMD_SS
 -  || diag == KDB_CMD_SSB
|| diag == KDB_CMD_KGDB)
   break;
  
 @@ -1368,12 +1358,6 @@ int kdb_main_loop(kdb_reason_t reason, kdb_reason_t 
 reason2, int error,
   break;
   }
  
 - if (result == KDB_CMD_SSB) {
 - KDB_STATE_SET(DOING_SS);
 -   

[Kgdb-bugreport] [GIT PULL] KGDB/KDB fixes for 3.9

[Jason Wessel]

Linus,

Please pull the kgdb tree's fixes/improvements.

For a change we removed more code than we added.  If people aren't using
it we shouldn't be carrying it. :-)

git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linus-3.9

Thanks,
Jason.

The following changes since commit d895cb1af15c04c522a25c79cc429076987c089b:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2013-02-26 20:16:07 
-0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linux-3.9

for you to fetch changes up to 397884d2e367aed778de69761181d85e348393bf:

  kdb: Remove unhandled ssb command (2013-03-02 06:53:22 -0600)


KGDB/KDB fixes and cleanups
 Cleanups
   Remove kdb ssb command - there is no in kernel disassembler to support it
   Remove kdb ll command - Always caused a kernel oops and there were no
   bug reports so no one was using this command
   Use kernel ARRAY_SIZE macro instead of array computations

 Fixes
   Stop oops in kdb if user executes kdb_defcmd with args
   kdb help command truncated text
   ppc64 support for kgdbts
   Add missing kconfig option from original kdb port for dealing with
  catastrophic kernel crashes such that you can reboot automatically
  on continue from kdb


Jason Wessel (4):
  kdb: Fix overlap in buffers with strcpy
  kdb_main: fix help print
  kdb: Remove the ll command
  kdb: Prevent kernel oops with kdb_defcmd

John Blackwood (1):
  kdb: A fix for kdb command table expansion

Matt Klein (1):
  kdb: Setup basic kdb state before invoking commands via kgdb

Robert Obermeier (1):
  Fixed dead ifdef block by adding missing Kconfig option.

Sasha Levin (1):
  kdb: use ARRAY_SIZE where possible

Tiejun Chen (1):
  kgdb/kgdbts: support ppc64

Vincent (1):
  kdb: Remove unhandled ssb command

 drivers/misc/kgdbts.c   |2 +
 kernel/debug/debug_core.h   |2 +
 kernel/debug/gdbstub.c  |3 +
 kernel/debug/kdb/kdb_bp.c   |   20 +-
 kernel/debug/kdb/kdb_debugger.c |   25 ++--
 kernel/debug/kdb/kdb_main.c |  135 +++
 kernel/debug/kdb/kdb_private.h  |4 --
 lib/Kconfig.kgdb|   18 ++
 8 files changed, 82 insertions(+), 127 deletions(-)

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] Fixed dead ifdef block by adding missing Kconfig option.

[Jason Wessel]

On 12/15/2012 10:59 PM, Robert Obermeier wrote:
 Added missing Kconfig option KDB_CONTINUE_CATASTROPHIC which lead to a dead 
 ifdef block in kernel/debug/kdb/kdb_main.c:73-75.

 The code using KDB_CONTINUE_CATASTROPHIC was originally introduced in 
 commit '5d5314d6795f3c1c0f415348ff8c51f7de042b77' by Jason Wessel.
 This patchset (kdb: core for kgdb back end (1 of 2))
 added platform independent part of kdb to the linux kernel.

 The Kernel option however, even though it had the same options and 
 behaviour on all supported architectures, was part of the x86 and
 ia64 patchset of KDB and therefore not pulled into the mainline kernel tree.

 I actually took the originally written Kconfig by 
 Keith Owens k...@sgi.com (2003-06-20 according to KDB changelog)
 and changed it to reflect the correct behaviour,
 as the KDUMP patchset is not part of the kernel and the expected 
 functionality is missing from it.

This is in my merge queue.

Thanks,
Jason.

--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 03/15] KDB: up the default LINES value

[Jason Wessel]

On 03/25/2013 01:50 PM, Mike Travis wrote:
 Currently the default for the # of lines displayed by the KDB pager
 is 24.  This does not allow all of the lines for the entry messages,
 reg dump and process trace.  Increase it to something more reasonable.
 


Unfortunately this is something that breaks compatibility with the
standard VGA console, so this patch will not be merged.

Is it the case that your hardware specifies how many lines and columns
there are in the display?  We have some hooks into the console VT code
to properly detect this but perhaps something is wrong there, or it is
only called in the KMS (kernel mode setting case).  Example:
drivers/tty/vt/vt.c - look at con_debug_enter()

Another option might be to add a variable which allows you to change
the default at compile time, but I would prefer to get the auto detect
code working properly if it is an option.

Jason.



 Cc: Tim Bird tim.b...@am.sony.com
 Reviewed-by: Dimitri Sivanich sivan...@sgi.com
 Signed-off-by: Mike Travis tra...@sgi.com
 ---
  kernel/debug/kdb/kdb_io.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 --- linux.orig/kernel/debug/kdb/kdb_io.c
 +++ linux/kernel/debug/kdb/kdb_io.c
 @@ -586,7 +586,7 @@ int vkdb_printf(const char *fmt, va_list
  
   diag = kdbgetintenv(LINES, linecount);
   if (diag || linecount = 1)
 - linecount = 24;
 + linecount = 60;
  
   diag = kdbgetintenv(COLUMNS, colcount);
   if (diag || colcount = 1)
 
 -- 
 


--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 01/15] KDB: fix the interrupt of the KDB btc command

[Jason Wessel]

On 03/25/2013 01:50 PM, Mike Travis wrote:
 The KDB 'btc' (backtrace cpus) command ignores the 'quit' reply
 to the 'more' prompt.  This is quite annoying when you have a
 large number of processors and thousands of lines are being
 printed.  This fixes that problem.
 

Merged to kgdb-next and added as a cc to -stable.

I'll be working my way through the rest of the patches in the series you sent 
and I'll merge anything that is going to -stable in the 3.9 series toward the 
end of the week assuming everything passes regression testing, and the rest 
will go into the 3.10 merge window.

Cheers,
Jason.

--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] kdb: kgdb: CONFIG_DEBUG_RODATA setting?

[Jason Wessel]

On 04/09/2013 08:06 AM, Sedat Dilek wrote:

  config DEBUG_RODATA
   bool Write protect kernel read-only data structures
 - default y
   depends on DEBUG_KERNEL
 + default n if KGDB
 + default y
   ---help---
 Mark the kernel read-only data as write-protected in the pagetables,
 in order to catch accidental (and incorrect) writes to such const


This is wrong and should not be merged.

A) You should not change these defaults in this manner

B) You have pointed out that the documentation is currently
   incorrect. The CONFIG_DEBUG_RODATA constraints were removed some time
   ago, per commit 3751d3e85cf693e10e2c47c03c8caa65e171099b (x86,kgdb:
   Fix DEBUG_RODATA limitation using text_poke())

Jason.


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] kgdb_mips64_watchpoint

[Jason Wessel]

On 07/24/2014 03:23 AM, skunlin wrote:
 Recently, when doing kgdb on my cpu which arch is mips_64, I encounter some 
 problems.


 arch : mips_64-octeon
 kernel-version: linux 2.6.32 


 when setting watchpoints on the kernel , it logs that 


 (gdb) watch jiffies
 Sending packet: $m80da0800,8#f6...Ack
 Packet received: 000126ae
 Sending packet: $m80da0800,8#f6...Ack
 Packet received: 000126ae
 Hardware watchpoint 1: jiffies


 (gdb) c
 Continuing.
 Sending packet: $m802cd42c,4#27...Ack
 Packet received: 000d
 Sending packet: $m80da0800,8#f6...Ack
 Packet received: 000126ae
 Sending packet: $Z2,80da0800,8#41...Ack
 Packet received: ==empty package
 Packet Z2 (write-watchpoint) is NOT supported
 Warning:
 Could not insert hardware watchpoint 1.
 Could not insert hardware breakpoints:
 You may have requested too many hardware breakpoints/watchpoints.


 then, I open the switch 
 (gdb) set remote write-watchpoint-packet on
 (gdb) c
 Continuing.
 Sending packet: $m802cd42c,4#27...Ack
 Packet received: 000d
 Sending packet: $m80da0800,8#f6...Ack
 Packet received: 000126ae
 Sending packet: $Z2,80da0800,8#41...Ack
 Packet received: 
 Enabled packet Z2 (write-watchpoint) not recognized by 
 stubstub no support watchpoint ?


 Searching the 
 http://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/log/?qt=grepq=mips
  , I was
 noticed that mips har support the hardware watchpoint on kgdb.

What specifically at the URL above led you to believe this?



 But when reading the kernel source code , only kgdb.c in .../x86/kernel which 
 define such functions like
 kgdb_set_hw_break / kgdb_remove_hw_break and so on. 


 That's confuse me so much.

There is no implementation of hardware breakpoints for the MIPS architecture 
for kprobes, kgdb,  or ptrace (used for user space gdb).  Any time I have ever 
dealt with hardware breakpoints it has been using a JTAG device with the MIPS 
architecture.

If you would like to contribute an implementation, it is always welcome of 
course.  Most MIPS CPUs have no way to deliver internal exceptions or program 
the hardware breakpoints however.

Cheers,
Jason.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] Some KGDB conceptual questions

[Jason Wessel]

On 10/09/2014 11:17 AM, joaoandrefe...@sapo.pt wrote:
 Hello all,
 
 I'm trying to use KGDB for some days now, and since I'm still getting  
 some errors that need to be fixed (working on it), I think that for  
 now it's better to ask here if what I'm trying to achieve is  
 theoretically possible with KGDB. I'm trying to do some kind of fault  
 injection, and so what I'm planning to do is:
 
 1. Interrupt whatever is running in the OS (this, of course, includes  
 the OS itself);


This is something you don't necessarily need kgdb/kdb for.  You might consider 
using a kprobe with a hardware break point, assuming you are on an architecture 
that has support, else you can strategically select your point of entry.


 
 2. Be able to call some kind of service routine to handle the  
 interruption (an interrupt handler, I guess). This interrupt handler  
 would inject a fault (e. g. bit-flip a breakpoint register, or the  
 stack of the process that was interrupted, etc, i.e. something  
 critical for the OS);
 
 3. Resume OS execution and be able to access the context of the  
 process interrupted (i. e.,  
 https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Context_switch.html);
 
 I know that it seems that some of these requirements are present in  
 KGDB, at least after reading the manual and some tutorials. But can  
 someone confirm or deny that the above is indeed possible with KGDB?  
 If the answer is positive, in a conceptual, general way, how would I  
 achieve that?
 


KGDB assumes there is an external agent talking to your running system.  It 
would seem you want to scramble some kernel memory on demand, and there is 
certainly more than one way to achieve that.  Certainly you can write a 
loadable kernel module or use a kprobe.

It almost seems like you are looking for the ability to inject a few commands 
to the kernel debugger and continue.  The kgdb test suite actually does do that 
because it pretends to be an I/O module (not unlike your serial port or 
keyboard).  This also requires you to create a kernel module however.  If you 
are looking for some kind of generic support to inject a command I had 
contemplated doing a few times, but have never really found a case that 
required it.

Cheers,
Jason.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] kdmx fails when 0xff is read from serial port

[Jason Wessel]

On 10/22/2014 02:12 AM, Frank Rowand wrote:
 From: Frank Rowand frank.row...@sonymobile.com

 kdmx incorrectly detects a 0xff character read from the serial port
 as a read error.  The false read error results in kdmx terminating.

 Signed-off-by: Frank Rowand frank.row...@sonymobile.com

Thanks! Patch applied.

Cheers,
Jason.

--
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] Instrument KGDB locally on target: is it possible?

[Jason Wessel]

On 11/06/2014 05:41 PM, Pete Delaney wrote:

 I'm wondering how complex (or possible) would be to instrument
 locally KGDB on the target machine, i. e., somehow remove the
 serial connection (and  the host machine, GDB) from the setup,
 since on this new scenario the host (GDB) and the target (KGDB)
 would run on the same machine. Is this idea as  absurd as it
 possibly seems?
 
 Yea, I suspect so.


I guess it depends what you are trying to do.  If you don't need to
stop the target system there is no reason you cannot just attach gdb
to the /dev/kmem.

Cheers,
Jason.

--
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] Getting Linux kernel symbols to resolve in kgdb

[Jason Wessel]

On 01/05/2015 03:19 PM, Jake Oshins wrote:
 Please forgive my ignorant question.  I'm very new to this.

 I've built a Linux kernel from a source tree cloned from Linus's tree with a 
 tag of v3.18.1 , which was from the middle of last month.  I've installed it 
 by building a Deb package and deploying it from the development machine to a 
 test machine, and uname tells me that I'm running that kernel.

 I've configured kgdb, and I see it connect at boot.  (I specified kgdbwait.)  
 I've also disable kernel-mode ASLR with nokaslr as a kernel parameter.  I 
 built the kernel with KGDB support turned on.  Specifically, I've chosen:

 CONFIG_SERIAL_KGDB_NMI=y
 CONFIG_HAVE_ARCH_KGDB=y
 CONFIG_KGDB=y
 CONFIG_KGDB_SERIAL_CONSOLE=y
 # CONFIG_KGDB_TESTS is not set
 CONFIG_KGDB_LOW_LEVEL_TRAP=y
 CONFIG_KGDB_KDB=y
 CONFIG_KDB_KEYBOARD=y
 CONFIG_KDB_CONTINUE_CATASTROPHIC=0


 I've started gdb by pointing it at the vmlinux image that I built, the same 
 one which is installed on the test machine.  And when it connects, I don't 
 see any symbol resolution.  Any attempt to do something which requires 
 symbols acts as if they don't exist.  Here's an example:

 (gdb) target remote /dev/ttyS0
 Remote debugging using /dev/ttyS0
 0x9e120bd4 in ?? ()
 (gdb) cont
 Continuing.
 [Inferior 1 (Remote target) exited with code 01]
 (gdb) cont
 The program is not being run.
 (gdb) target remote /dev/ttyS0
 Remote debugging using /dev/ttyS0
 0x85120bd4 in ?? ()
 (gdb) bt
 #0  0x85120bd4 in ?? ()
 #1  0x88002350fe38 in ?? ()
 #2  0x85121d0e in ?? ()
 #3  0x in ?? ()

 Can somebody point me at a FAQ, or otherwise help me figure out how to get 
 symbol resolution working?


https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/CompilingAKernel.html#CompileKGDB


Make sure you are using CONFIG_DEBUG_INFO as mentioned in the docs.  :-)

Jason.

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] kgdb-next not pushed to Linus for 3.19

[Jason Wessel]

On 01/06/2015 03:21 PM, Andrew Morton wrote:
 On Tue, 06 Jan 2015 10:57:42 -0800 Joe Perches j...@perches.com wrote:

 On Tue, 2015-01-06 at 18:54 +, Daniel Thompson wrote:
 Hi Jason

 I'm trying to figure out what to do with my long-outstanding kgdb/kdb
 patches in preparation for the 3.20 merge window.

 As of now I have five pending patch sets some of which are well over six
 months old (and none have nay outstanding review comments).

 When I raised this with you a couple of months ago, two of the patch
 sets did land in your kgdb-next tree. However nothing seems to have
 happened since then and I couldn't find any messages from you during the
 3.19 merge window.

 I'm afraid I don't know what else I need to do to progress things.

 I do plan to do routine rebasing and resending of my patchsets but,
 based on the past experience, that seems unlikely to be enough to get
 the code delivered in 3.20.

 Do you think I would be better sending these patches via someone else?
 In any case, advice would be very welcome.
 Andrew?

 I think Daniel's kgdb patches are bug fixes.

 Can you please pick them up?
 yup.  Merging patches which are already in -next is a bit of a pain,
 but I'll cope.

 Daniel, can you please resend everything in a nice clean coherent
 stream?


I did not mean to miss the merge window, but I ended up being out the majority 
of December - yesterday.

Now that I am back, I don't think you have to burden Andrew here.  I'll send a 
pull request for what is in kgdb-next since it is cleanups and fixes, and 
regression test anything else Daniel has left.

Cheers,
Jason.


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] kgdb: fix potential out-of-bounds access

[Jason Wessel]

On 01/12/2015 01:45 PM, Brian Norris wrote:
 CPU arrays (e.g., kgdb_info[]) are indexed from 0 (inclusive) to NR_CPUS
 (exclusive).

 Pointed out by Coverity, CID 1262269

 Signed-off-by: Brian Norris computersforpe...@gmail.com
 Cc: Jason Wessel jason.wes...@windriver.com
 ---
 Untested

  kernel/debug/kdb/kdb_main.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
 index f191bddf64b8..53f051853f14 100644
 --- a/kernel/debug/kdb/kdb_main.c
 +++ b/kernel/debug/kdb/kdb_main.c
 @@ -2256,7 +2256,7 @@ static int kdb_cpu(int argc, const char **argv)
   /*
* Validate cpunum
*/
 - if ((cpunum  NR_CPUS) || !kgdb_info[cpunum].enter_kgdb)
 + if ((cpunum = NR_CPUS) || !kgdb_info[cpunum].enter_kgdb)
   return KDB_BADCPUNUM;
  
   dbg_switch_cpu = cpunum;


This is actually already fixed a different way in the kgdb-next:

https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/commit/?h=kgdb-nextid=c7d9ebf81c456dc185c8eae9e293bfdccf2a65f5



diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 8f4bb40..b25eb80 100644
--- a/kernel/debug/kdb/kdb_main.c 
https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/tree/kernel/debug/kdb/kdb_main.c?h=kgdb-nextid=9705097e962127b07c0aeea64aacd5302126920b
+++ b/kernel/debug/kdb/kdb_main.c 
https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/tree/kernel/debug/kdb/kdb_main.c?h=kgdb-nextid=c7d9ebf81c456dc185c8eae9e293bfdccf2a65f5
@@ -2256,7 +2256,7 @@ static int kdb_cpu(int argc, const char **argv)
/*
* Validate cpunum
*/
- if ((cpunum  NR_CPUS) || !kgdb_info[cpunum].enter_kgdb)
+ if ((cpunum = CONFIG_NR_CPUS) || !kgdb_info[cpunum].enter_kgdb)
return KDB_BADCPUNUM;
dbg_switch_cpu = cpunum;

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [GIT PULL] KGDB/KDB fixes for 3.19-rc4

[Jason Wessel]

Linus,

Please pull the kgdb tree bug fixes.

These have been around since 3.17 and in kgdb-next for the last 9
weeks and some will go back to -stable.

Summary of changes:

KGDB/KDB fixes and cleanups
 Cleanups
   kdb: Remove unused command flags, repeat flags and KDB_REPEAT_NONE

 Fixes
   kgdb/kdb: Allow access on a single core, if a CPU round up is deemed
  impossible, which will allow inspection of the now trashed kernel
   kdb: Add enable mask for the command groups
   kdb: access controls to restrict sensitive commands 


git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linus-3.19-rc4

Thanks,
Jason.

The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108:

  Linux 3.18-rc4 (2014-11-09 14:55:29 -0800)

are available in the git repository at:

  . kgdb-next

for you to fetch changes up to 0f16996cf2ed7c368dd95b4c517ce572b96a10f5:

  kernel/debug/debug_core.c: Logging clean-up (2014-11-11 09:31:53 -0600)


Anton Vorontsov (6):
  kdb: Remove currently unused kdbtab_t-cmd_flags
  kdb: Rename kdb_repeat_t to kdb_cmdflags_t, cmd_repeat to cmd_flags
  kdb: Rename kdb_register_repeat() to kdb_register_flags()
  kdb: Use KDB_REPEAT_* values as flags
  kdb: Remove KDB_REPEAT_NONE flag
  kdb: Add enable mask for groups of commands

Daniel Thompson (3):
  kdb: Categorize kdb commands (similar to SysRq categorization)
  kdb: Allow access to sensitive commands to be restricted by default
  kgdb: timeout if secondary CPUs ignore the roundup

Fabian Frederick (1):
  kernel/debug/debug_core.c: Logging clean-up

 include/linux/kdb.h |  62 --
 kernel/debug/debug_core.c   |  52 
 kernel/debug/kdb/kdb_bp.c   |  37 +++---
 kernel/debug/kdb/kdb_debugger.c |   4 +
 kernel/debug/kdb/kdb_main.c | 267 +---
 kernel/debug/kdb/kdb_private.h  |   3 +-
 kernel/trace/trace_kdb.c|   4 +-
 lib/Kconfig.kgdb|  25 
 8 files changed, 306 insertions(+), 148 deletions(-)

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] kdb: Fix handling of kallsyms_symbol_next() return value

[Jason Wessel]

On 03/02/2015 08:13 AM, Daniel Thompson wrote:
 kallsyms_symbol_next() returns a boolean (true on success). Currently
 kdb_read() tests the return value with an inequality that
 unconditionally evaluates to true.
 
 This is fixed in the obvious way and, since the conditional branch is
 supposed to be unreachable, we also add a WARN_ON().
 


Thanks.  Applied to kgdb-next.  I'll send it along to the upstream
before the end of the v4.0 cycle, we'll see if we pickup any other
fixes along the way. :-)

Cheers,
Jason.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] using sysrq-trigger to start kgdb

[Jason Wessel]

On 07/29/2015 08:45 AM, נעמה ממן wrote:
 Hello,



 cross compiled raspberry pi kernel using an Ubuntu virtual machine.

 Using this configurations:



 CONFIG_DEBUG_INFO=y

 CONFIG_MAGIC_SYSRQ=y
 CONFIG_FRAME_POINTER=y
 CONFIG_KGDB=y
 CONFIG_KGDB_SERIAL_CONSOLE=y

 CONFIG_KGDB_KDB=y
 CONFIG_KDB_KEYBOARD=y

 The pc is connected to RPI by UART.

 Want to debug the raspberry pi kernel with kdbkgdb.



 using the minicom (in vm host) to send the break signal (alt+a ,f(send
 break) ,g(Go)) kdbkgdb is working as expected

 when trying to use echo g  /proc/sysrq-trigger get the message :

 Entering kdb (current=0xc054ca80, pid 0) due to Keyboard Entry

 kdb_

 kdb stuck and doesn’t response to keyboard, so i cant enter kgdb :/

 Do you have any suggestion why?

I have seem problems like this in the past and it is usually the case that the 
UART polling hooks are not written properly, or that the kernel is blocked on a 
lock, somewhere.  Considering that you made it to the KDB prompt with no 
critical printks, I would suspect the UART driver is probably the issue.

Jason.

--
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 4/4] drivers/misc: make kgdbts.c slightly more explicitly non-modular

[Jason Wessel]

On 08/08/2015 03:35 PM, Paul Gortmaker wrote:
 The Kconfig currently controlling compilation of this code is:

 lib/Kconfig.kgdb:config KGDB_TESTS
 lib/Kconfig.kgdb:   bool KGDB: internal test suite

 ...meaning that it currently is not being built as a module by anyone.

 Lets remove the modular code that is essentially orphaned, so that
 when reading the driver there is no doubt it is builtin-only.

 Since module_init translates to device_initcall in the non-modular
 case, the init ordering remains unchanged with this commit.

 We also delete the MODULE_LICENSE tag etc. since all that information
 is already contained at the top of the file in the comments.

 We can't remove the module.h include since we've kept the use of
 module_param in this file for now.


This is correct, if you remove that there is no way to invoke the test suite 
later on at run time.

I tried out the patch and it works fine with no regressions.

Unrelated to this it seems there is a problem with the read/write of the break 
points when crossing the point where the kernel write protects the read-only 
data.  Basically, the break point is implanted into the code page, which is 
made read-only, and then it can no longer be removed.  What we typically do in 
that case after read-only pages are established, is to use COW pages for the 
break points.  I'll have to look further into what if anything we might have to 
do about it. At least the emergency printk logic worked to show there is a 
problem. :-)

Acked-by: Jason Wessel jason.wes...@windriver.com


--
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH -repost] kgdb: depends on VT

[Jason Wessel]

On 03/31/2016 03:29 AM, Jiri Slaby wrote:
> With VT=n, the kernel build fails with:
> drivers/built-in.o: In function `kgdboc_pre_exp_handler':
> kgdboc.c:(.text+0x7b5aa): undefined reference to `fg_console'
> kgdboc.c:(.text+0x7b5ce): undefined reference to `vc_cons'
> kgdboc.c:(.text+0x7b5d5): undefined reference to `vc_cons'
>
> kgdboc.o is built when KGDB_SERIAL_CONSOLE is set. So make
> KGDB_SERIAL_CONSOLE depend on HW_CONSOLE which includes those symbols.

Acked-by: Jason Wessel <jason.wes...@windriver.com>


I'll put this in the kgdb-next branch and submit it to the upstream, unless it 
gets merged in another queue.

Thanks!
Jason.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [RESEND PATCH] arm64: kgdb: fix single stepping

[Jason Wessel]

On 04/20/2015 08:13 PM, AKASHI Takahiro wrote:
> Jason,
>
> Could you please review my patch below?
> See also arm64 maintainer's comment:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313712.html
>
> Thanks,
> -Takahiro AKASHI
>
> I tried to verify kgdb in vanilla kernel on fast model, but it seems that
> the single stepping with kgdb doesn't work correctly since its first
> appearance at v3.15.
>
> On v3.15, 'stepi' command after breaking the kernel at some breakpoint
> steps forward to the next instruction, but the succeeding 'stepi' never
> goes beyond that.
> On v3.16, 'stepi' moves forward and stops at the next instruction just
> after enable_dbg in el1_dbg, and never goes beyond that. This variance of
> behavior seems to come in with the following patch in v3.16:
>
> commit 2a2830703a23 ("arm64: debug: avoid accessing mdscr_el1 on fault
> paths where possible")
>
> This patch
> (1) moves kgdb_disable_single_step() from 'c' command handling to single
> step handler.
> This makes sure that single stepping gets effective at every 's' command.
> Please note that, under the current implementation, single step bit in
> spsr, which is cleared by the first single stepping, will not be set
> again for the consecutive 's' commands because single step bit in mdscr
> is still kept on (that is, kernel_active_single_step() in
> kgdb_arch_handle_exception() is true).
> (2) re-implements kgdb_roundup_cpus() because the current implementation
> enabled interrupts naively. See below.
> (3) removes 'enable_dbg' in el1_dbg.
> Single step bit in mdscr is turned on in do_handle_exception()->
> kgdb_handle_expection() before returning to debugged context, and if
> debug exception is enabled in el1_dbg, we will see unexpected single-
> stepping in el1_dbg.
> Since v3.18, the following patch does the same:
>   commit 1059c6bf8534 ("arm64: debug: don't re-enable debug exceptions
>   on return from el1_dbg)
> (4) masks interrupts while single-stepping one instruction.
> If an interrupt is caught during processing a single-stepping, debug
> exception is unintentionally enabled by el1_irq's 'enable_dbg' before
> returning to debugged context.
> Thus, like in (2), we will see unexpected single-stepping in el1_irq.
>
> Basically (1) and (2) are for v3.15, (3) and (4) for v3.1[67].
>
> @@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, 
> int signo,
>* over and over again.
>*/
>   kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
> - atomic_set(_cpu_doing_single_step, -1);
> - kgdb_single_step =  0;


This is a subtle change, but I assume it is what you intended?  All the CPUs 
will get released into the run state when exiting the kgdb exception handler.


> -
> - /*
> -  * Received continue command, disable single step
> -  */
> - if (kernel_active_single_step())
> - kernel_disable_single_step();
>


I see why this is not needed above any more given that you have a function that 
cleans up the state on entry to the kgdb exception handler.

The rest of the patch is fine.

I added the patch to kgdb-next after fixing up the context since it no longer 
applied to the mainline ( 
https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/log/?h=kgdb-next).
  If there is further discussion on the point above, another patch can be 
added, but it I am assuming this is the way you desire it to work as there are 
some other architectures that use the same behaviour.  I do not presently have 
any ARM64 hardware to validate this particular change.

I also added to the patch a "Cc: linux-stable " so we 
can have this appear on some of the older kernels.


Thanks,
Jason.


--
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [RESEND PATCH] arm64: kgdb: fix single stepping

[Jason Wessel]

On 09/15/2016 05:41 AM, Daniel Thompson wrote:
> On 15/09/16 08:56, AKASHI Takahiro wrote:
>> On Wed, Sep 14, 2016 at 03:58:51PM +0100, Will Deacon wrote:
>>> Hi Akashi,
>>>
>>> On Tue, Apr 21, 2015 at 02:13:13AM +0100, AKASHI Takahiro wrote:
 Could you please review my patch below?
 See also arm64 maintainer's comment:
 http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313712.html
>>>
>>> -ETIMEDOUT waiting for the kdgb folk to comment. Ppeople have reported
>>> that this patch is required for kgdb to work correctly on arm64, so I'm
>>> happy to merge it.
>>
>> I'm happy, too.
>
> I'll keep an eye out and FWIW see if I can throw in a review. I'm not
> really one of "kgdb folk" but did examine it fairly deeply in the early
> stages of the FIQ/NMI work (and which has since stopped focussing on kgdb).
>
> I have some equally elderly, albeit rather less critical, kdb patches
> that I should have pushed harder for so I'm sympathetic here ;-)


Hey, if you do happen to have something, why not send it along.  I just asked 
the linux-next folks to re-activate the kgdb-next branch so that merges can 
start taking place again.  It appears that the final merge request never even 
went through from linux-next as I just rebased it and there was a patch in 
there from Daniel dating back to over a year ago.

If there is work out there that needs merging and reviews lets get it done.  I 
had been kind of stuck in time on what seems like the stone age 3.14 kernel 
projects until recently, but jumped back into mainline development about a 
month ago.

I have no objection to merging the ARM64 single step patch and have comments in 
a separate mail that follows with respect to the patch.


Cheers,
Jason.

--
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [RESEND PATCH] arm64: kgdb: fix single stepping

[Jason Wessel]

On 09/15/2016 11:32 PM, AKASHI Takahiro wrote:
> @@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, 
> int signo,
>>>  * over and over again.
>>>  */
>>> kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
>>> -   atomic_set(_cpu_doing_single_step, -1);
>>> -   kgdb_single_step =  0;
>>
>> This is a subtle change, but I assume it is what you intended?  All the CPUs 
>> will get released into the run state when exiting the kgdb exception handler.
> You are talking about "- kgdb_single_step = 0." Right?


Correct.

> Do you think that there is any (negative) side effect of this change?


Not at all.   The kernel debugger always skids to a stop, and it is more 
reliable from a locking perspective if the other CPU threads are released while 
a single CPU is asked to single step until the next "skid" for all the other 
CPUs.

When you do not release the other CPUs you can end up single stepping a CPU 
which dead locks or never exits a lock elsewhere due to what ever it was 
blocking on never getting freed from another CPU.

Cheers,
Jason.

--
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [RESEND PATCH] arm64: kgdb: fix single stepping

[Jason Wessel]

On 09/16/2016 02:45 AM, Will Deacon wrote:
> On Fri, Sep 16, 2016 at 01:32:19PM +0900, AKASHI Takahiro wrote:
>> On Thu, Sep 15, 2016 at 08:04:57AM -0500, Jason Wessel wrote:
>>> I added the patch to kgdb-next after fixing up the context since it no
>>> longer applied to the mainline (
>>> https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/log/?h=kgdb-next).
>>> If there is further discussion on the point above, another patch can be
>>> added, but it I am assuming this is the way you desire it to work as
>>> there are some other architectures that use the same behaviour.  I do
>>> not presently have any ARM64 hardware to validate this particular
>>> change.
>>>
>>> I also added to the patch a "Cc: linux-stable <sta...@vger.kernel.org>"
>>> so we can have this appear on some of the older kernels.
>> Since Will asked me to split this patch into a few, I need some reworks
>> to clarify which hunks in the patch are necessary for which version of 
>> kernel.
> Yes, splitting the patch would be much better for sorting out the stable
> backports too. Jason, please can you drop the patch for now? I don't mind
> whether the end result goes via arm64 or kgdb, but we should at least both
> agree on it first :)

Splitting it is a very wise idea so that we can have all the -stable kernels 
patched up with a working single step function.

The separated patches can easily be tagged with the CC line examples as shown 
below:

Cc: <sta...@vger.kernel.org> # 3.15.x-
Cc: <sta...@vger.kernel.org> # 4.4
Cc: <sta...@vger.kernel.org> # 4.4-4.5

I had dropped the original patch.

Cheers,
Jason.


--
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

[Jason Wessel]

On 12/05/2017 08:09 AM, Lee Jones wrote:

On Tue, 05 Dec 2017, Daniel Thompson wrote:


... with many, many thanks for Jason for all his hard work.

Cc: Jason Wessel <jason.wes...@windriver.com>
Signed-off-by: Daniel Thompson <daniel.thomp...@linaro.org>
---

Notes:
 Over the years Jason has become increasingly hard to get hold off
 and I think he must now be regarded as inactive.
 
 Patches in kgdb-next (mine as it happens) have been there for over a

 year without a corresponding pull request and a couple of architecture
 specific kgdb fixes have ended up missing a release cycle (or two) as
 the architecture maintainer waits for an Acked-by from Jason.
 
 In the past I've had to rely on Andrew M. to land my own changes to

 kgdb and in the v4.14 cycle you'll find my Acked-by on b8347c219649
 ("x86/debug: Handle warnings before the notifier chain, to fix KGDB
 crash"). That I was sharing surrogate acks convinced me we need a
 change here and I've offered Jason help via private e-mail without
 reply.
 
 So, I really would prefer it it if this patch listed me as a

 co-maintainer or, failing that, as least had Jason's blessing... but
 it doesn't. I certainly suggest this patch takes a long time in
 review, and if it doesn't attract Jason's attention then I can only
 reiterate what is says in the commit log: Thanks Jason!

  MAINTAINERS | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)


It looks like Jason has been inactive in all aspects of upstream
maintainership and as a contributor for well over a year now.


I have not been working directly on upstream kernel contributions for quite 
some time.  It doesn't mean I haven't been involved with kernel development.  
Patches that I have reviewed or suggested to other developers generally don't 
bare my name.  I wouldn't mind trying to take a slightly more gradual passing 
of the baton and add Daniel as co-maintainer for a while before I retire from 
kernel work and merge myself away in the coming years. :-)

I have a series of 50+ patches for kgdb/kdb/usb which have never been 
published.  I am not saying that we actually need any of those patches, but it 
would be nice to let the community decide, and we can see if there is anything 
worth merging into the next cycle or future work with other maintainers.   My 
kernel.org tree stopped working a long time ago, probably from inactivity.  
I'll see if that can get restored in the next few days, or I'll use my github 
tree and send the unpublished work to the mailing list as an RFC.  And for what 
it is worth if none of this happens by the end of 4.16, by all means Daniel has 
my blessing to be the sole maintainer.

Many thanks to Daniel for his contributions!

Cheers,
Jason.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] misc: kgdbts: Display progress of asynchronous tests

[Jason Wessel]

On 12/12/2017 06:10 AM, Daniel Thompson wrote:

kgdbts includes a couple of different "thrashing" style tests that
may have long runtimes (especially on simulated platforms) and which
run asynchronously. This is uncomfortable for interactive use and
makes setting timeouts tricky for automatic use.



Do you know which test was specifically causing a problem?  It might not be 
documented anywhere but I had usually started a user space process which 
quickly created and deleted user space processes in order to make the kgdbts 
tests complete quickly.

I don't really see any issue with emitting a printk to indicate progress as it 
is debug only and test specific.  As you know printk's change timing.  If I had 
a dime for each time I had seen a problem go away when I started adding 
printk's I'd have at least a 50 cents.  :-)


Jason.

PS.  Added this to kgdb-next and I'll put in a request to get kgdb-next added 
back to the linux-next builder.



Fix by providing a optional means to show progress during these tests.
Selecting 100 is somewhat arbitrary but it matches the step used on
the synchronous tests, is large enough to keep the call to printk
from invalidating the testing and is human enough to "feel about
right".

Signed-off-by: Daniel Thompson 
---
  drivers/misc/kgdbts.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 24108bfad889..6193270e7b3d 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -400,10 +400,14 @@ static void skip_back_repeat_test(char *arg)
int go_back = simple_strtol(arg, NULL, 10);

repeat_test--;
-   if (repeat_test <= 0)
+   if (repeat_test <= 0) {
ts.idx++;
-   else
+   } else {
+   if (repeat_test % 100 == 0)
+   v1printk("kgdbts:RUN ... %d remaining\n", repeat_test);
+
ts.idx -= go_back;
+   }
fill_get_buf(ts.tst[ts.idx].get);
  }

--
2.14.3




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 2/3] kdb: drop newline in unknown command output

[Jason Wessel]

On 12/08/2017 12:19 PM, Randy Dunlap wrote:

From: Randy Dunlap <rdun...@infradead.org>





Thanks for the series Randy.   I'll get these applied, but I will take
a look at changing this patch slightly.



When an unknown command is entered, kdb prints "Unknown kdb command:"
and then the unknown text, including the newline character. This
causes the ending single-quote mark to be printed on the next line
by itself, so just change the ending newline character to a null
character (end of string) so that it won't be "printed."

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Daniel Thompson <daniel.thomp...@linaro.org>
Cc: Jason Wessel <jason.wes...@windriver.com>
Cc: kgdb-bugreport@lists.sourceforge.net
---
  kernel/debug/kdb/kdb_main.c |   11 +++
  1 file changed, 11 insertions(+)

--- lnx-415-rc1.orig/kernel/debug/kdb/kdb_main.c
+++ lnx-415-rc1/kernel/debug/kdb/kdb_main.c
@@ -1150,6 +1150,16 @@ void kdb_set_current_task(struct task_st
kdb_current_regs = NULL;
  }
  
+static void drop_newline(char *buf)

+{
+   size_t len = strlen(buf);
+
+   if (len == 0)
+   return;
+   if (*(buf + len - 1) == '\n')
+   *(buf + len - 1) = '\0';
+}
+
  /*
   * kdb_local - The main code for kdb.  This routine is invoked on a
   *specific processor, it is not global.  The main kdb() routine
@@ -1327,6 +1337,7 @@ do_full_getstr:
cmdptr = cmd_head;
diag = kdb_parse(cmdbuf);
if (diag == KDB_NOTFOUND) {
+   drop_newline(cmdbuf);



We might be able to get away with just adjusting the pointer in the kdb_parse 
instead of adding the drop_newline because we are returning error anyway and 
the parse needs to be called again in the future for a new command.


Thanks,
Jason.


kdb_printf("Unknown kdb command: '%s'\n", cmdbuf);
diag = 0;
}





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH 2/2] kgdb/kdb/debug_core: Add co-maintainer Daniel Thompson

[Jason Wessel]

On 12/06/2017 06:52 PM, Randy Dunlap wrote:

On 12/06/2017 02:33 PM, Jason Wessel wrote:

  L:kgdb-bugreport@lists.sourceforge.net
  T:git git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git



I would urge you to move to a different mailing list server.


No argument here, considering some of the past problems with the mail list.  I 
put in a request to get a list created on vger, and it can be migrated after it 
gets created.

Thanks,
Jason.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [GIT PULL] KGDB/KDB fixes for 4.15-rc2

[Jason Wessel]

Linus,

Please pull the kgdb tree.

Summary of changes:
   * Fix long standing problem with kdb kallsyms_symbol_next() return value
   * Add new co-maintainer Daniel Thompson

git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linus-4.15-rc2

Thanks,
Jason.

The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4:

  Linux 4.14 (2017-11-12 10:46:13 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linus-4.15-rc2

for you to fetch changes up to 4e23f78c74934e8ea624b59df58e646e0657608a:

  kgdb/kdb/debug_core: Add co-maintainer Daniel Thompson (2017-12-06 16:12:43 
-0600)


KGDB:
   * Fix long standing problem with kdb kallsyms_symbol_next() return value
   * Add new co-maintainer Daniel Thompson


Daniel Thompson (1):
  kdb: Fix handling of kallsyms_symbol_next() return value

Jason Wessel (1):
  kgdb/kdb/debug_core: Add co-maintainer Daniel Thompson

 MAINTAINERS   | 1 +
 kernel/debug/kdb/kdb_io.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 1/2] kdb: Fix handling of kallsyms_symbol_next() return value

[Jason Wessel]

From: Daniel Thompson <daniel.thomp...@linaro.org>

kallsyms_symbol_next() returns a boolean (true on success). Currently
kdb_read() tests the return value with an inequality that
unconditionally evaluates to true.

This is fixed in the obvious way and, since the conditional branch is
supposed to be unreachable, we also add a WARN_ON().

Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Daniel Thompson <daniel.thomp...@linaro.org>
Cc: linux-stable <sta...@vger.kernel.org>
Signed-off-by: Jason Wessel <jason.wes...@windriver.com>
---
 kernel/debug/kdb/kdb_io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index e74be38..ed5d349 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -350,7 +350,7 @@ static char *kdb_read(char *buffer, size_t bufsize)
}
kdb_printf("\n");
for (i = 0; i < count; i++) {
-   if (kallsyms_symbol_next(p_tmp, i) < 0)
+   if (WARN_ON(!kallsyms_symbol_next(p_tmp, i)))
break;
kdb_printf("%s ", p_tmp);
*(p_tmp + len) = '\0';
-- 
1.9.1


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

[Kgdb-bugreport] [PATCH 2/2] kgdb/kdb/debug_core: Add co-maintainer Daniel Thompson

[Jason Wessel]

Signed-off-by: Jason Wessel <jason.wes...@windriver.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2811a21..74be63b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7659,6 +7659,7 @@ F:security/keys/
 
 KGDB / KDB /debug_core
 M: Jason Wessel <jason.wes...@windriver.com>
+M: Daniel Thompson <daniel.thomp...@linaro.org>
 W: http://kgdb.wiki.kernel.org/
 L: kgdb-bugreport@lists.sourceforge.net
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git
-- 
1.9.1


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] kdb: use __ktime_get_real_seconds instead of __current_kernel_time

[Jason Wessel]

On 10/13/2017 03:26 AM, Daniel Thompson wrote:

On 12/10/17 23:40, Andrew Morton wrote:

On Thu, 12 Oct 2017 16:06:11 +0200 Arnd Bergmann  wrote:


kdb is the only user of the __current_kernel_time() interface, which is
not y2038 safe and should be removed at some point.

The kdb code also goes to great lengths to print the time in a
human-readable format from 'struct timespec', again using a non-y2038-safe
re-implementation of the generic time_to_tm() code.


Is it really necessary for the kdb `summary' command to print the
time/date?  Which puppies would die if we just removed it all?


kdb may enter spontaneously (BUG(), etc) so it can be useful if one
returns from an overnight test run to know how long things survived.

It would almost certainly be possible for a skilled user to reconstruct
the time of death. Having said that, one of the things you can do with
kdb (although I admit *I* have never done it) is leave a macro command
in the hands of an unskilled user.

Short summary: no puppies would die, but perhaps some might go hungry
for a little while when their owner is late home?



Daniel is correct.  This is information that was just a nice to have for 
postmortem analysis it can also be called via gdb macros.

If kdb is really the last remaining user, it seems like the interface should 
get removed and kdb can print time another way that is compatible with the 2038 
fixes.

After having taken a quick look it would seem __ktime_get_real_seconds()  (because we 
need the non-lock protected version) and time64_to_tm() should be the proper replacement. 
 There is certainly no reason to duplicate code in kdb for the "summary" 
functions.

I am assuming no one has fixed this yet, so I should be able to provide a patch 
to the list along the lines of what is below.  And I will follow it with a 
second patch to remove the __current_kernel_time() to lkml and the timekeeper 
maintainer.

Cheers,
Jason.

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 09168c52ab64..2529cc470a45 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -53,6 +53,8 @@ extern void getrawmonotonic64(struct timespec64 *ts);
 extern void ktime_get_ts64(struct timespec64 *ts);
 extern time64_t ktime_get_seconds(void);
 extern time64_t ktime_get_real_seconds(void);
+/* does not take xtime_lock */
+extern time64_t __ktime_get_real_seconds(void);
 
 extern int __getnstimeofday64(struct timespec64 *tv);

 extern void getnstimeofday64(struct timespec64 *tv);
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 2a20c0dfdafc..c7a02710d884 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -2477,41 +2477,6 @@ static int kdb_kill(int argc, const char **argv)
return 0;
 }
 
-struct kdb_tm {

-   int tm_sec; /* seconds */
-   int tm_min; /* minutes */
-   int tm_hour;/* hours */
-   int tm_mday;/* day of the month */
-   int tm_mon; /* month */
-   int tm_year;/* year */
-};
-
-static void kdb_gmtime(struct timespec *tv, struct kdb_tm *tm)
-{
-   /* This will work from 1970-2099, 2100 is not a leap year */
-   static int mon_day[] = { 31, 29, 31, 30, 31, 30, 31,
-31, 30, 31, 30, 31 };
-   memset(tm, 0, sizeof(*tm));
-   tm->tm_sec  = tv->tv_sec % (24 * 60 * 60);
-   tm->tm_mday = tv->tv_sec / (24 * 60 * 60) +
-   (2 * 365 + 1); /* shift base from 1970 to 1968 */
-   tm->tm_min =  tm->tm_sec / 60 % 60;
-   tm->tm_hour = tm->tm_sec / 60 / 60;
-   tm->tm_sec =  tm->tm_sec % 60;
-   tm->tm_year = 68 + 4*(tm->tm_mday / (4*365+1));
-   tm->tm_mday %= (4*365+1);
-   mon_day[1] = 29;
-   while (tm->tm_mday >= mon_day[tm->tm_mon]) {
-   tm->tm_mday -= mon_day[tm->tm_mon];
-   if (++tm->tm_mon == 12) {
-   tm->tm_mon = 0;
-   ++tm->tm_year;
-   mon_day[1] = 28;
-   }
-   }
-   ++tm->tm_mday;
-}
-
 /*
  * Most of this code has been lifted from kernel/timer.c::sys_sysinfo().
  * I cannot call that code directly from kdb, it has an unconditional
@@ -2537,8 +2502,8 @@ static void kdb_sysinfo(struct sysinfo *val)
  */
 static int kdb_summary(int argc, const char **argv)
 {
-   struct timespec now;
-   struct kdb_tm tm;
+   time64_t now_seconds;
+   struct tm tm;
struct sysinfo val;
 
 	if (argc)

@@ -2552,9 +2517,9 @@ static int kdb_summary(int argc, const char **argv)
kdb_printf("domainname %s\n", init_uts_ns.name.domainname);
kdb_printf("ccversion  %s\n", __stringify(CCVERSION));
 
-	now = __current_kernel_time();

-   kdb_gmtime(, );
-   kdb_printf("date   %04d-%02d-%02d %02d:%02d:%02d "
+   now_seconds = __ktime_get_real_seconds();
+   time64_to_tm(now_seconds, sys_tz.tz_minuteswest * 60, );
+   kdb_printf("date   

Re: [Kgdb-bugreport] [PATCH] kdb: use __ktime_get_real_seconds instead of __current_kernel_time

[Jason Wessel]

On 10/12/2017 09:06 AM, Arnd Bergmann wrote:

kdb is the only user of the __current_kernel_time() interface, which is
not y2038 safe and should be removed at some point.

The kdb code also goes to great lengths to print the time in a
human-readable format from 'struct timespec', again using a non-y2038-safe
re-implementation of the generic time_to_tm() code.

Using __current_kernel_time() here is necessary since the regular
accessors that require a sequence lock might hang when called during the
xtime update. However, this is safe in the particular case since kdb is
only interested in the tv_sec field that is updated atomically.

In order to make this y2038-safe, I'm converting the code to the generic
time64_to_tm helper, but that introduces the problem that we have no
interface like __current_kernel_time() that provides a 64-bit timestamp
in a lockless, safe and architecture-independent way. I have multiple
ideas for how to solve that:

- __ktime_get_real_seconds() is lockless, but can return
   incorrect results on 32-bit architectures in the special case that
   we are in the process of changing the time across the epoch, either
   during the timer tick that overflows the seconds in 2038, or while
   calling settimeofday.

- ktime_get_real_fast_ns() would work in this context, but does
   require a call into the clocksource driver to return a high-resolution
   timestamp. This may have undesired side-effects in the debugger,
   since we want to limit the interactions with the rest of the kernel.

- Adding a ktime_get_real_fast_seconds() based on tk_fast_mono
   plus tkr->base_real without the tk_clock_read() delta. Not sure about
   the value of adding yet another interface here.

- Changing the existing ktime_get_real_seconds() to use
   tk_fast_mono on 32-bit architectures rather than xtime_sec.  I think
   this could work, but am not entirely sure if this is an improvement.

I picked the first of those for simplicity here. It's technically
not correct but probably good enough as the time is only used for the
debugging output and the race will likely never be hit in practice.
Another downside is having to move the declaration into a public header
file.

Let me know if anyone has a different preference.



It all seems reasonable to me.  Separately I created the same patch because I 
didn't see this mail first.  The only difference was that I added a comment 
about the __ktime_get_real_seconds() not taking the lock because it was done 
that way in other places in the header file.

===
 extern time64_t ktime_get_real_seconds(void);
+/* does not take xtime_lock */
+extern time64_t __ktime_get_real_seconds(void);
===

Acked-by: Jason Wessel <jason.wes...@windriver.com>

Thanks for your work on the 2038 problems.  :-)

Cheers,
Jason.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

[Jason Wessel]

On 12/05/2017 10:42 AM, Randy Dunlap wrote:

On 12/05/2017 06:55 AM, Daniel Thompson wrote:

On 05/12/17 14:37, Jason Wessel wrote:

I have a series of 50+ patches for kgdb/kdb/usb which have never been 
published.  I am not saying that we actually need any of those patches, but it 
would be nice to let the community decide, and we can see if there is anything 
worth merging into the next cycle or future work with other maintainers.   My 
kernel.org tree stopped working a long time ago, probably from inactivity.  
I'll see if that can get restored in the next few days, or I'll use my github 
tree and send the unpublished work to the mailing list as an RFC.


I, for one, would be interested to see these.


Me also.  I have 3 kdb patches that I just made.




If you have some patches please do send them along to the list.  I have added 
Daniel as an additional maintainer for when I am not around.

We are open for business again now that my kernel.org tree accepts my tag 
signing again.  It will take some time to go through these unpublished patches 
to see what is actually relevant, but I'll posting some of them to the mailing 
reasonably list soon.

Cheers,
Jason.

ps

While on the topic of debuggers...  I was thinking it might be interesting to 
have a gdb-serial stub in an FPGA for debugging the kernel not unlike what was 
done with the firewire debugger that Andi Kleen worked on long ago.  I am not 
exactly sure what kind of run control options exist there but in terms of 
accessing memory it would certainly be plausible to access it.  One option I 
know that is plausible for run control is a small kernel interrupt handler 
perhaps for the run control interface based on the fact you can some FPGAs show 
up like a PCI device.

While I haven't been directly working in upstream linux in last year or two, I 
still do plenty of debugging of full systems with simulators, hardware, and now 
FPGAs too.  :-)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

[Jason Wessel]

On 12/05/2017 08:55 AM, Daniel Thompson wrote:

On 05/12/17 14:37, Jason Wessel wrote:

On 12/05/2017 08:09 AM, Lee Jones wrote:

On Tue, 05 Dec 2017, Daniel Thompson wrote:


... with many, many thanks for Jason for all his hard work.

Cc: Jason Wessel <jason.wes...@windriver.com>
Signed-off-by: Daniel Thompson <daniel.thomp...@linaro.org>
---

Notes:
  Over the years Jason has become increasingly hard to get hold off
  and I think he must now be regarded as inactive.
  Patches in kgdb-next (mine as it happens) have been there for
over a
  year without a corresponding pull request and a couple of
architecture
  specific kgdb fixes have ended up missing a release cycle (or
two) as
  the architecture maintainer waits for an Acked-by from Jason.
  In the past I've had to rely on Andrew M. to land my own changes to
  kgdb and in the v4.14 cycle you'll find my Acked-by on b8347c219649
  ("x86/debug: Handle warnings before the notifier chain, to fix KGDB
  crash"). That I was sharing surrogate acks convinced me we need a
  change here and I've offered Jason help via private e-mail without
  reply.
  So, I really would prefer it it if this patch listed me as a
  co-maintainer or, failing that, as least had Jason's blessing...
but
  it doesn't. I certainly suggest this patch takes a long time in
  review, and if it doesn't attract Jason's attention then I can only
  reiterate what is says in the commit log: Thanks Jason!

   MAINTAINERS | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

It looks like Jason has been inactive in all aspects of upstream
maintainership and as a contributor for well over a year now.

I have not been working directly on upstream kernel contributions for
quite some time.  It doesn't mean I haven't been involved with kernel
development.  Patches that I have reviewed or suggested to other
developers generally don't bare my name.  I wouldn't mind trying to take
a slightly more gradual passing of the baton and add Daniel as
co-maintainer for a while before I retire from kernel work and merge
myself away in the coming years. :-)

Great to hear from you again! I shall consider this patch nacked or the
time being ;-)... and if you are happy with help from me I shall leave
it to you to propose an update to MAINTAINERS.



I have a series of 50+ patches for kgdb/kdb/usb which have never been
published.  I am not saying that we actually need any of those patches,
but it would be nice to let the community decide, and we can see if
there is anything worth merging into the next cycle or future work with
other maintainers.   My kernel.org tree stopped working a long time ago,
probably from inactivity.  I'll see if that can get restored in the next
few days, or I'll use my github tree and send the unpublished work to
the mailing list as an RFC.

I, for one, would be interested to see these.



Dropped LKML.   I did figure out why I wasn't getting all Daniel's mails.  The 
kgdb list had a bad filter and was just collecting mail and not sending it.  I 
never saw the mail Daniel referenced from October and November until today.  
Oopps...

Thanks again to Daniel for shepherding the fixes along through the other 
maintainers trees.

Daniel you are now a co-owner to the kgdb list so you'll get messages about 
rejections of posts and such.  If other folks on the list get some old mails 
from the last few months today, it is because I cleared the blocked mail queue 
on Source Forge where the list is hosted.

Jason.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

[Jason Wessel]

On 12/05/2017 09:14 AM, Lee Jones wrote:



Will you also be drafting a MAINTAINERS patch to identify Daniel as
co-maintainer?  If you're busy, either myself or I'm sure Daniel will
be happy to author one.



I'll take care of it and get it pushed to the tree.  I'd like to get a signed 
tag pushed on to the end of the kernel.org kgdb-next tree but I need to get 
access to it, first.  That way I can submit a pull req to Linus.

Cheers,
Jason.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport