From: Daniel Thompson <daniel.thompson@linaro.org>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
Sumit Garg <sumit.garg@linaro.org>,
Jason Wessel <jason.wessel@windriver.com>,
Douglas Anderson <dianders@chromium.org>,
kgdb-bugreport@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>
Subject: Re: [PATCH] printk/kdb: Redirect printk messages into kdb in any context
Date: Fri, 15 May 2020 14:48:06 +0100 [thread overview]
Message-ID: <20200515134806.5cw4xxnxw7k3223l@holly.lan> (raw)
In-Reply-To: <20200515103308.GD42471@jagdpanzerIV.localdomain>
On Fri, May 15, 2020 at 07:33:08PM +0900, Sergey Senozhatsky wrote:
> On (20/05/15 10:50), Petr Mladek wrote:
> > kdb is able to stop kernel even in NMI context where printk() is redirected
> > to the printk_safe() lockless variant. Move the check and redirect to kdb
> > even in this case.
>
> Can I please have some context what problem does this solve?
> I can see that vkdb_printf() calls into console drivers:
>
> for_each_console(c) {
> c->write(c, cp, retlen - (cp - kdb_buffer));
> touch_nmi_watchdog();
> }
>
> Is this guaranteed that we never execute this path from NMI?
Absolutely not.
The execution context for kdb is pretty much unique... we are running a
debug mode with all CPUs parked in a holding loop with interrupts
disabled. One CPU is at an unknown exception state and the others are
either handling an IRQ or NMI depending on architecture[1].
However there are a number of factors that IMHO weigh in favour of
allowing kdb to intercept here.
1. kgdb/kdb are designed to work from NMI, modulo the bugs that are
undoubtedly present.
2. A synchronous breakpoint (including an implicit breakpoint-on-oops)
from any code that executes with irqs disabled will exhibit most of
the same problems as an NMI but without waking up all the NMI logic.
3. kdb_trap_printk is only set for *very* narrow time intervals by the
debug master (the single CPU in the system that is *not* in a
holding loop). Thus in all cases the system has already successfully
executed kdb_printf() several times before we ever call the printk()
interception code.
Or put another way, even if we did tickle a bug speculated about in
#1, it won't be the call to printk() that triggers it; we'd never
get that far!
> If so, can this please be added to the commit message? A more
> detailed commit message will help a lot.
I suspect Petr might prefer any future flames about kdb_printf() to be
pointed at me rather than him ;-) so if adding anything to the commit
message then I'd suggest it be based on the reasoning in #3 above.
Daniel.
next prev parent reply other threads:[~2020-05-15 13:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 8:48 [PATCH] kgdb: Fix broken handling of printk() in NMI context Sumit Garg
2020-05-12 14:25 ` Daniel Thompson
2020-05-13 13:34 ` Sumit Garg
2020-05-14 8:42 ` Petr Mladek
2020-05-15 5:46 ` Sumit Garg
2020-05-15 8:50 ` [PATCH] printk/kdb: Redirect printk messages into kdb in any context Petr Mladek
2020-05-15 10:33 ` Sergey Senozhatsky
2020-05-15 12:02 ` Sumit Garg
2020-05-15 16:36 ` Sergey Senozhatsky
2020-05-15 16:52 ` Doug Anderson
2020-05-18 6:19 ` Sumit Garg
2020-06-10 16:41 ` Daniel Thompson
2020-06-11 7:27 ` Sergey Senozhatsky
2020-06-11 7:58 ` Petr Mladek
2020-05-15 13:48 ` Daniel Thompson [this message]
2020-05-15 16:24 ` Sergey Senozhatsky
2020-05-18 9:21 ` Petr Mladek
2020-05-20 4:21 ` Sergey Senozhatsky
2020-05-20 9:35 ` Daniel Thompson
2020-05-20 10:22 ` [PATCH v2] " Petr Mladek
2020-05-20 11:17 ` Sergey Senozhatsky
2020-05-20 16:07 ` 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=20200515134806.5cw4xxnxw7k3223l@holly.lan \
--to=daniel.thompson@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=dianders@chromium.org \
--cc=jason.wessel@windriver.com \
--cc=john.ogness@linutronix.de \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=sumit.garg@linaro.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.