public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: sergey.senozhatsky@gmail.com, linux-kernel@vger.kernel.org,
	rostedt@goodmis.org, mingo@kernel.org, tglx@linutronix.de,
	Jason Wessel <jason.wessel@windriver.com>
Subject: Re: [PATCH 1/3] printk: Fix kdb_trap_printk placement
Date: Thu, 5 Oct 2017 15:38:44 +0200	[thread overview]
Message-ID: <20171005133844.GA16068@pathway.suse.cz> (raw)
In-Reply-To: <20170928122513.328354788@infradead.org>

On Thu 2017-09-28 14:18:24, Peter Zijlstra wrote:
> Some people figured vprintk_emit() makes for a nice API and exported
> it, bypassing the kdb trap.
> 
> This still leaves vprintk_nmi() outside of the kbd reach, should that
> be fixed too?
> 
> Cc: Jason Wessel <jason.wessel@windriver.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  kernel/printk/printk.c |   18 ++++++------------
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1811,6 +1811,11 @@ asmlinkage int vprintk_emit(int facility
>  	int printed_len;
>  	bool in_sched = false;
>  
> +#ifdef CONFIG_KGDB_KDB
> +	if (unlikely(kdb_trap_printk && kdb_printf_cpu < 0))
> +		return vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args);
> +#endif

Hmm, this will get called also from scheduler and timer code
via printk_deferred(). I am afraid that it is not safe.

If I get it correctly, vkdb_printf() might call printk()
when kdb_printf_cpu are set to a real CPU number. Then
we will fall through and try to call consoles.


Fortunately, I think that we do not need this patch at all.
vkdb_printf() is called here only when kdb_trap_printk is set.
It is used the following way:

static void kdb_dumpregs(struct pt_regs *regs)
{
[...]
	kdb_trap_printk++;
	show_regs(regs);
	kdb_trap_printk--;
[...]
}

or 

static int kdb_ftdump(int argc, const char **argv)
{
[...]
	kdb_trap_printk++;
	ftrace_dump_buf(skip_lines, cpu_file);
	kdb_trap_printk--;
[...]
}

It looks like a nasty hack to reuse an existing code
that calls printk(). The aim is to get the output
of these printk's on the kdb console instead of
the log buffer and other consoles.

Note that kdb_dumpregs(), kdb_ftdump() implement
kdb commands that might be called from the kdb console.

If these commands are always called from normal context
then we do not need to care of NMI and other special printk
variants.

Or can the kdb console commands be called in NMI context?

Best Regards,
Petr

  parent reply	other threads:[~2017-10-05 13:38 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-28 12:18 [PATCH 0/3] printk: Add force_early_printk boot param Peter Zijlstra
2017-09-28 12:18 ` [PATCH 1/3] printk: Fix kdb_trap_printk placement Peter Zijlstra
2017-10-03 22:10   ` Steven Rostedt
2017-10-05 13:38   ` Petr Mladek [this message]
2017-10-05 13:42     ` Peter Zijlstra
2017-10-09 15:05       ` Petr Mladek
2017-10-12  9:45   ` Petr Mladek
2017-10-12 10:03     ` Petr Mladek
2017-10-12 11:34       ` Peter Zijlstra
2017-10-12 11:52         ` Greg Kroah-Hartman
2017-10-12 12:08           ` Greg Kroah-Hartman
2017-10-12 18:11             ` Joe Perches
2017-10-13 14:23               ` Petr Mladek
2017-10-12 11:30     ` Peter Zijlstra
2017-09-28 12:18 ` [PATCH 2/3] early_printk: Add force_early_printk kernel parameter Peter Zijlstra
2017-09-28 15:41   ` Randy Dunlap
2017-09-28 16:07     ` Peter Zijlstra
2017-09-28 17:05       ` Randy Dunlap
2017-10-03 22:18   ` Steven Rostedt
2017-10-12 10:24   ` Petr Mladek
2017-10-12 11:39     ` Peter Zijlstra
2017-10-13 13:06       ` Petr Mladek
2017-10-13 13:20         ` Peter Zijlstra
2017-10-13 13:30         ` Steven Rostedt
2017-09-28 12:18 ` [PATCH 3/3] early_printk: Add simple serialization to early_vprintk() Peter Zijlstra
2017-10-03 22:24   ` Steven Rostedt
2017-10-04  9:08     ` Peter Zijlstra
2017-10-04 13:04       ` Steven Rostedt
2017-10-04 13:08         ` Peter Zijlstra
2017-10-04 14:17         ` Paul E. McKenney
2017-10-04 14:43           ` Steven Rostedt
2017-10-04 14:52             ` Peter Zijlstra
2017-10-04 15:02               ` Steven Rostedt
2017-10-04 15:14               ` Paul E. McKenney
2017-10-04 15:24           ` Peter Zijlstra
2017-10-04 15:38             ` Paul E. McKenney
2017-09-28 16:02 ` [PATCH 0/3] printk: Add force_early_printk boot param Sergey Senozhatsky
2017-09-28 16:17   ` Peter Zijlstra
  -- strict thread matches above, loose matches on Subject: below --
2016-10-18 17:08 [PATCH 0/3] make printk work again Peter Zijlstra
2016-10-18 17:08 ` [PATCH 1/3] printk: Fix kdb_trap_printk placement Peter Zijlstra
2016-10-19 14:41   ` Petr Mladek
2016-10-19 15:18     ` Peter Zijlstra
2016-10-20 13:02   ` Sergey Senozhatsky
2016-11-29 13:54   ` Petr Mladek

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=20171005133844.GA16068@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    /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