linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jason Wessel <jason.wessel@windriver.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] kdb: Call vkdb_printf() from vprintk_default() only when wanted
Date: Tue, 22 Nov 2016 13:45:16 +0100	[thread overview]
Message-ID: <20161122124516.GD8220@pathway.suse.cz> (raw)
In-Reply-To: <73b8fe23-4fc7-9d56-ed78-a3d6b398ad74@linaro.org>

On Mon 2016-11-07 10:24:22, Daniel Thompson wrote:
> On 21/10/16 13:50, Petr Mladek wrote:
> >kdb_trap_printk allows to pass normal printk() messages to kdb via
> >vkdb_printk(). For example, it is used to get backtrace using
> >the classic show_stack(), see kdb_show_stack().
> >
> >vkdb_printf() tries to avoid a potential infinite loop by disabling
> >the trap. But this approach is racy, for example:
> >
> >CPU1					CPU2
> >
> >vkdb_printf()
> >  // assume that kdb_trap_printk == 0
> >  saved_trap_printk = kdb_trap_printk;
> >  kdb_trap_printk = 0;
> >
> >					kdb_show_stack()
> >					  kdb_trap_printk++;
> 
> When kdb is running any of the commands that use kdb_trap_printk
> there is a single active CPU and the other CPUs should be in a
> holding pen inside kgdb_cpu_enter().
> 
> The only time this is violated is when there is a timeout waiting
> for the other CPUs to report to the holding pen.

It means that the race window is small but it is there. Do I get
it correctly, please?

Thanks a lot for explanation. I was not sure how exactly this worked.
I only saw the games with kdb_printf_cpu in vkdb_printf(). Therefore
I expected that some parallelism was possible.

> 
> >diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> >index d5e397315473..db73e33811e7 100644
> >--- a/kernel/printk/printk.c
> >+++ b/kernel/printk/printk.c
> >@@ -1941,7 +1941,9 @@ int vprintk_default(const char *fmt, va_list args)
> > 	int r;
> >
> > #ifdef CONFIG_KGDB_KDB
> >-	if (unlikely(kdb_trap_printk)) {
> >+	/* Allow to pass printk() to kdb but avoid a recursion. */
> >+	if (unlikely(kdb_trap_printk &&
> >+		     kdb_printf_cpu != smp_processor_id())) {
> 
> Firstly, why !=?
>
> Secondly, if kdb_trap_printk is set and the "wrong" CPU calls printk
> then we have an opportunity to trap a rouge processor in the holding
> pen meaning the test should probably be part of vkdb_printk()
> anyway.

I agree that it is confusing:

On one hand, vkdb_printf() explicitly allows recursion on the same
CPU. See the handling of kdb_printf_lock before the 1st patch from
this series. Also it mentioned by the comment:

	/* Serialize kdb_printf if multiple cpus try to write at once.
	 * But if any cpu goes recursive in kdb, just print the output,
	 * even if it is interleaved with any other text.
	 */


On the other hand. The lines

       saved_trap_printk = kdb_trap_printk;
       kdb_trap_printk = 0;

means that someone wanted to explicitly disable recursion via
the generic printk(). This is the reason why I used "!=" and why
I added this check into vprintk_default().


By other words, we allow recursion caused by kdb internal messages
that are printed directly by kdb_printf()). But we disable recursion
caused by all other messages that are printed using the generic
printk(). This patch keeps the logic. It might make some sense.
But it is hard for me to judge.

Best Regards,
Petr

  reply	other threads:[~2016-11-22 12:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 12:50 [PATCH 0/2] kdb: Fix locking in vkdb_printf() Petr Mladek
2016-10-21 12:50 ` [PATCH 1/2] kdb: Properly synchronize vkdb_printf() calls with other CPUs Petr Mladek
2016-11-07 10:07   ` Daniel Thompson
2016-11-22 10:34     ` Petr Mladek
2016-10-21 12:50 ` [PATCH 2/2] kdb: Call vkdb_printf() from vprintk_default() only when wanted Petr Mladek
2016-10-23 13:23   ` Sergey Senozhatsky
2016-11-22 12:14     ` Petr Mladek
2016-11-07 10:24   ` Daniel Thompson
2016-11-22 12:45     ` Petr Mladek [this message]
2016-11-22 14:32       ` Daniel Thompson
2016-11-23 16:29         ` 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=20161122124516.GD8220@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.thompson@linaro.org \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=sergey.senozhatsky@gmail.com \
    /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).