From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/10] arm64/BUG: Show explicit backtrace for WARNs
Date: Tue, 16 Jun 2015 15:49:44 +0100 [thread overview]
Message-ID: <20150616144944.GF30522@arm.com> (raw)
In-Reply-To: <1434036566-9848-11-git-send-email-Dave.Martin@arm.com>
On Thu, Jun 11, 2015 at 04:29:24PM +0100, Dave P Martin wrote:
> The generic slowpath WARN implementation prints a backtrace, but
> the report_bug() based implementation does not, opting to print the
> registers instead which is generally not as useful.
>
> Ideally, report_bug() should be fixed to make the behaviour more
> consistent, but in the meantime this patch generates a backtrace
> directly from the arm64 backend instead so that this functionality
> is not lost with the migration to report_bug().
>
> As a side-effect, the backtrace will be outside the oops end
> marker, but that's hard to avoid without modifying generic code.
>
> This patch can go away if report_bug() grows the ability in the
> future to generate a backtrace directly or call an arch hook at the
> appropriate time.
Could you propose a patch to the core code, please? I'm happy to merge this
in the interim, but it sounds like a simple oversight.
Will
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> ---
> arch/arm64/kernel/traps.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 5fdf776..8929c16 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -489,6 +489,9 @@ static int bug_handler(struct pt_regs *regs, unsigned int esr)
> /* die() does not return */
>
> case BUG_TRAP_TYPE_WARN:
> + /* Ideally, report_bug() should backtrace for us... but no. */
> + dump_backtrace(regs, NULL);
> +
> regs->pc += AARCH64_INSN_SIZE; /* skip BRK and resume */
> return DBG_HOOK_HANDLED;
>
> --
> 1.7.10.4
>
next prev parent reply other threads:[~2015-06-16 14:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 15:29 [PATCH 00/10] arm64: Use BRK instruction for generic BUG traps Dave Martin
2015-06-11 15:29 ` [PATCH 01/10] arm64/debug: Eliminate magic number for size of BRK instruction Dave Martin
2015-06-11 15:29 ` [PATCH 02/10] arm64/debug: Mask off all reserved bits from generated ESR values Dave Martin
2015-06-11 15:29 ` [PATCH 03/10] arm64: esr.h type fixes and cleanup Dave Martin
2015-06-11 15:29 ` [PATCH 04/10] arm64/debug: Eliminate magic number from ESR template definition Dave Martin
2015-06-11 15:29 ` [PATCH 05/10] arm64/debug: More consistent naming for the BRK ESR template macro Dave Martin
2015-06-11 15:29 ` [PATCH 06/10] arm64/debug: Move BRK ESR template macro into <asm/esr.h> Dave Martin
2015-06-11 15:29 ` [PATCH 07/10] arm64/debug: Simplify BRK insn opcode declarations Dave Martin
2015-06-11 15:29 ` [PATCH 08/10] arm64/debug: Move BRK types to a separate header Dave Martin
2015-06-11 15:29 ` [PATCH 09/10] arm64/BUG: Use BRK instruction for generic BUG traps Dave Martin
2015-06-16 14:48 ` Will Deacon
2015-06-17 11:35 ` Dave Martin
2015-06-17 16:42 ` Will Deacon
2015-06-11 15:29 ` [PATCH 10/10] arm64/BUG: Show explicit backtrace for WARNs Dave Martin
2015-06-16 14:49 ` Will Deacon [this message]
2015-06-17 11:13 ` Dave Martin
2015-06-16 14:51 ` [PATCH 00/10] arm64: Use BRK instruction for generic BUG traps Will Deacon
2015-06-16 16:51 ` Dave Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150616144944.GF30522@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.