From: Daniel Thompson <daniel.thompson@linaro.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: jason.wessel@windriver.com, gregkh@linuxfoundation.org,
kgdb-bugreport@lists.sourceforge.net, mingo@redhat.com,
hpa@zytor.com, bp@alien8.de, linux-serial@vger.kernel.org,
agross@kernel.org, tglx@linutronix.de, frowand.list@gmail.com,
bjorn.andersson@linaro.org, jslaby@suse.com,
catalin.marinas@arm.com, corbet@lwn.net, will@kernel.org,
Matt Mullins <mmullins@fb.com>, Nadav Amit <namit@vmware.com>,
Peter Zijlstra <peterz@infradead.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v2 4/9] kgdb: Delay "kgdbwait" to dbg_late_init() by default
Date: Mon, 27 Apr 2020 16:42:01 +0100 [thread overview]
Message-ID: <20200427154201.dxkoctjxta22u7hz@holly.lan> (raw)
In-Reply-To: <20200421141234.v2.4.I3113aea1b08d8ce36dc3720209392ae8b815201b@changeid>
On Tue, Apr 21, 2020 at 02:14:42PM -0700, Douglas Anderson wrote:
> Using kgdb requires at least some level of architecture-level
> initialization. If nothing else, it relies on the architecture to
> pass breakpoints / crashes onto kgdb.
>
> On some architectures this all works super early, specifically it
> starts working at some point in time before Linux parses
> early_params's. On other architectures it doesn't. A survey of a few
> platforms:
>
> a) x86: Presumably it all works early since "ekgdboc" is documented to
> work here.
> b) arm64: Catching crashes works; with a simple patch breakpoints can
> also be made to work.
> c) arm: Nothing in kgdb works until
> paging_init() -> devicemaps_init() -> early_trap_init()
>
> Let's be conservative and, by default, process "kgdbwait" (which tells
> the kernel to drop into the debugger ASAP at boot) a bit later at
> dbg_late_init() time. If an architecture has tested it and wants to
> re-enable super early debugging, they can implement the weak function
> kgdb_arch_can_debug_early() to return true. We'll do this for x86 to
> start. It should be noted that dbg_late_init() is still called quite
> early in the system.
>
> Note that this patch doesn't affect when kgdb runs its init. If kgdb
> is set to initialize early it will still initialize when parsing
> early_params's. This patch _only_ inhibits the initial breakpoint
> from "kgdbwait". This means:
>
> * Without any extra patches arm64 platforms will at least catch
> crashes after kgdb inits.
> * arm platforms will catch crashes (and could handle a hardcoded
> kgdb_breakpoint()) any time after early_trap_init() runs, even
> before dbg_late_init().
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
Overall this looks good but there is a small quibble below...
> diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
> index b072aeb1fd78..7371517aeacc 100644
> --- a/include/linux/kgdb.h
> +++ b/include/linux/kgdb.h
> @@ -226,6 +226,28 @@ extern int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt);
> */
> extern void kgdb_arch_late(void);
>
> +/**
> + * kgdb_arch_can_debug_early - Check if OK to break before dbg_late_init()
> + *
> + * If an architecture can definitely handle entering the debugger when
> + * early_param's are parsed then it can override this function to return
> + * true. Otherwise if "kgdbwait" is passed on the kernel command line it
> + * won't actually be processed until dbg_late_init() just after the call
> + * to kgdb_arch_late() is made.
> + *
> + * NOTE: Even if this returns false we will still try to register kgdb to
> + * handle breakpoints and crashes when early_params's are parsed, we just
> + * won't act on the "kgdbwait" parameter until dbg_late_init(). If you
> + * get a crash and try to drop into kgdb somewhere between these two
> + * places you might or might not end up being able to use kgdb depending
> + * on exactly how far along the architecture has initted.
> + *
> + * ALSO: dbg_late_init() is actually still fairly early in the system
> + * boot process.
> + *
> + * Return: true if platform can handle kgdb early.
> + */
> +extern bool kgdb_arch_can_debug_early(void);
Does this need to be a function? It looks like all implementations are
either return true or return false (e.g. CONFIG_ARCH_HAVE_EARLY_DEBUG
would do the same thing).
Daniel.
next prev parent reply other threads:[~2020-04-27 15:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 21:14 [PATCH v2 0/9] kgdb: Support late serial drivers; enable early debug w/ boot consoles Douglas Anderson
2020-04-21 21:14 ` [PATCH v2 1/9] kgdb: Disable WARN_CONSOLE_UNLOCKED for all kgdb Douglas Anderson
2020-04-27 13:40 ` Daniel Thompson
2020-04-21 21:14 ` [PATCH v2 2/9] Revert "kgdboc: disable the console lock when in kgdb" Douglas Anderson
2020-04-27 13:41 ` Daniel Thompson
2020-04-21 21:14 ` [PATCH v2 3/9] kgdboc: Use a platform device to handle tty drivers showing up late Douglas Anderson
2020-04-27 14:19 ` Daniel Thompson
2020-04-21 21:14 ` [PATCH v2 4/9] kgdb: Delay "kgdbwait" to dbg_late_init() by default Douglas Anderson
2020-04-27 15:42 ` Daniel Thompson [this message]
2020-04-21 21:14 ` [PATCH v2 5/9] arm64: Add call_break_hook() to early_brk64() for early kgdb Douglas Anderson
2020-04-27 16:52 ` Daniel Thompson
2020-04-21 21:14 ` [PATCH v2 6/9] kgdboc: Add earlycon_kgdboc to support early kgdb using boot consoles Douglas Anderson
2020-04-27 16:36 ` Daniel Thompson
2020-04-28 21:32 ` Doug Anderson
2020-04-21 21:14 ` [PATCH v2 7/9] Documentation: kgdboc: Document new earlycon_kgdboc parameter Douglas Anderson
2020-04-27 16:46 ` Daniel Thompson
2020-04-28 21:32 ` Doug Anderson
2020-04-21 21:14 ` [PATCH v2 8/9] serial: qcom_geni_serial: Support earlycon_kgdboc Douglas Anderson
2020-04-27 16:48 ` Daniel Thompson
2020-04-21 21:14 ` [PATCH v2 9/9] serial: 8250_early: " Douglas Anderson
2020-04-27 16:50 ` Daniel Thompson
2020-04-23 13:50 ` [PATCH v2 0/9] kgdb: Support late serial drivers; enable early debug w/ boot consoles Greg KH
2020-04-24 8:32 ` Sumit Garg
2020-04-24 10:13 ` Daniel Thompson
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=20200427154201.dxkoctjxta22u7hz@holly.lan \
--to=daniel.thompson@linaro.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dianders@chromium.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jason.wessel@windriver.com \
--cc=jslaby@suse.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mmullins@fb.com \
--cc=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).