Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751206AbbLLGEl (ORCPT ); Sat, 12 Dec 2015 01:04:41 -0500 Received: from mail-io0-f182.google.com ([209.85.223.182]:33988 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbbLLGEk (ORCPT ); Sat, 12 Dec 2015 01:04:40 -0500 MIME-Version: 1.0 Date: Fri, 11 Dec 2015 23:04:39 -0700 Message-ID: Subject: [PATCH 1/1] Fix kdb erroneously reporting an INT3 breakpoint is a catastrophic error From: Jeff Merkey To: LKML Cc: Jason Wessel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2515 Lines: 54 The default kdb setting for entry assumes that a system oops was triggered rather than a request for debugger entry. When an application codes an int3 breakpoint the intent is to break into a debugger -- that's what the instruction is for. I noticed that kdb and kgdb both use an int3 breakpoint to trigger debugger entry from the sysrq-trigger interface. So it seems odd that it would treat another int3 as a catastrophic error. I would also like to discuss the possibility of a simple registration interface in kgdboc for the mdb debugger and addition of the text string "mdb" to select which debugger is active so the system debuggers don't step all over each other that will allow other debuggers to register and for us to share the "g" sysrq-trigger key. At present, I disable kdb/kgdb on module load and would like to put together something more friendly for folks using it. I really like the interface in kgdboc for selecting which debugger is active. You are always welcome to be involved in mdb is you wish or are bored. Since it has tagged and deref disassembly and just runs on the machine as a module, its easier to setup and use than kgdb and is not headless like kdb. There are a lot of folks using it based on emails I get and the small but constant downloads over the last 15 years I have distributed it. This patch changes the default so when kdb sees another int3 breakpoint, it enters the debugger (which is does anyway) but without the enter multiple times message to continue and thinking a catastrophic error has occurred. I have tested kdb/kgdb with mdb both active and have it setup so they don't crash each other but its better to not ping pong between consoles. At any rate, I offer the peace pipe ... Signed-off-by: Jeff V. Merkey diff --git a/kernel/debug/kdb/kdb_debugger.c b/kernel/debug/kdb/kdb_debugger.c index 15e1a7a..d9b944d 100644 --- a/kernel/debug/kdb/kdb_debugger.c +++ b/kernel/debug/kdb/kdb_debugger.c @@ -55,7 +55,7 @@ int kdb_stub(struct kgdb_state *ks) int error = 0; kdb_bp_t *bp; unsigned long addr = kgdb_arch_pc(ks->ex_vector, ks->linux_regs); - kdb_reason_t reason = KDB_REASON_OOPS; + kdb_reason_t reason = KDB_REASON_KEYBOARD; kdb_dbtrap_t db_result = KDB_DB_NOBPT; int i; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/