From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753626AbbAGPm5 (ORCPT ); Wed, 7 Jan 2015 10:42:57 -0500 Received: from mail-wi0-f169.google.com ([209.85.212.169]:56520 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752672AbbAGPm4 (ORCPT ); Wed, 7 Jan 2015 10:42:56 -0500 From: Daniel Thompson To: Jason Wessel Cc: Daniel Thompson , linux-kernel@vger.kernel.org, kgdb-bugreport@lists.sourceforge.net, Andrew Morton , Ingo Molnar , patches@linaro.org, linaro-kernel@lists.linaro.org, John Stultz , Sumit Semwal Subject: [RESEND PATCH v3.19-rc2] kdb: Remove stack dump when entering kgdb due to NMI Date: Wed, 7 Jan 2015 15:42:32 +0000 Message-Id: <1420645352-2790-1-git-send-email-daniel.thompson@linaro.org> X-Mailer: git-send-email 1.9.3 In-Reply-To: <1405518033-11671-1-git-send-email-daniel.thompson@linaro.org> References: <1405518033-11671-1-git-send-email-daniel.thompson@linaro.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Issuing a stack dump feels ergonomically wrong when entering due to NMI. Entering due to NMI is normally a reaction to a user request, either the NMI button on a server or a "magic knock" on a UART. Therefore the backtrace behaviour on entry due to NMI should be like SysRq-g (no stack dump) rather than like oops. Note also that the stack dump does not offer any information that cannot be trivial retrieved using the 'bt' command. Signed-off-by: Daniel Thompson Cc: Jason Wessel --- kernel/debug/kdb/kdb_main.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c index 379650b984f8..f9ba42363132 100644 --- a/kernel/debug/kdb/kdb_main.c +++ b/kernel/debug/kdb/kdb_main.c @@ -1207,7 +1207,6 @@ static int kdb_local(kdb_reason_t reason, int error, struct pt_regs *regs, kdb_printf("due to NonMaskable Interrupt @ " kdb_machreg_fmt "\n", instruction_pointer(regs)); - kdb_dumpregs(regs); break; case KDB_REASON_SSTEP: case KDB_REASON_BREAK: -- 1.9.3